Inconsistent handling of cluster names in Antares Web APIs

[makdeuneuv]

Update the functions for editing Antares studies in AntaresWeb APIs so that they are no longer case-sensitive, allowing a cluster or zone name to be passed in upper or lower case.

TODO: add context. Enumerate the end points that can have this issue.

The names must not be changed but the API queries should be case-insensitive.

[create-issue-branch[bot]]

Branch feature/issue-1228-Managing_Antares_object_names_in_AntaresWeb_APIs created!

[laurent-laporte-pro]

Currently, the configuration of thermal and renewable clusters (as well as soon-to-be short-term storages) is done in an INI file. Here is an example from the file input/thermal/clusters/at/list.ini:

[AT_batteries_inj]
name = AT_batteries_inj
group = other
unitcount = 1
nominalcapacity = 88.000000

[AT_batteries_pcomp_inj]
name = AT_batteries_pcomp_inj
group = other
enabled = false

...

This INI file contains sections enclosed in brackets, such as [AT_batteries_inj], and the parameters for each thermal cluster. Within these parameters, there is a parameter called name = AT_batteries_inj, which may seem redundant with the section name. However, it is not redundant because the section name must be a unique identifier. In other words, it is (normally) not possible to have two sections with the same name.

Furthermore, I would also like to remind you that within a section, parameter names should (normally) appear only once (but that's another story).

The issue of uppercase and lowercase letters does not lie in the INI file itself but rather in certain parts of the programs. Sometimes, we need to calculate an identifier based on a name. To do this, we use a function called transform_name_to_id, which converts a name to lowercase (and removes certain characters) to obtain the identifier. It is important to note that this function comes from the Antares Solver project.

If we are not careful, the name "AT_batteries_inj" will be converted to "at_batteries_inj," which does not match the section name. As a result, an anomaly will be raised as an HTTP 500 error (KeyError).

In summary, there are two actions to take:

1. Correct the programs to use the section name instead of attempting to calculate an identifier from a name.
2. Correct the R scripts that provide data to have lowercase section names that adhere to the constraints of the transform_name_to_id function.

These actions alone will not be sufficient because there are numerous studies that contain this error and consider the identifier to be strictly the same as the name. Therefore, it is necessary to be more cautious and take the existing situation into account.

[laurent-laporte-pro]

To better understand the stakes, let's consider the following scenario:

1. The user creates a thermal cluster using the API, which should return the ID of the newly created cluster (similar to how it's done with objects stored in a database, for example).
2. Subsequently, this ID will be used to modify or delete the cluster.

Therefore, if the API returns an ID that is not the name, there will be an issue.

Note: Currently, when using the create_cluster command with the API, no response is returned. Therefore, there is currently no way to obtain the ID of the newly created cluster. This functionality is missing and needs to be addressed.