-
Task
-
Resolution: Done
-
Major
-
2.7 GA
-
3
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
Not Started
-
3scale 2019-12-09, 3scale 2020-03-09, 3scale 2020-03-23
In 2.7, with APIAP and Backend metrics, we chose to append the Backend's ID to the system_name of each of the Backend's metrics. This was required to prevent naming collisions at the Product level, once we sync'ed those Backend metrics as belonging to each Product using the Backend. That's all right. However, we also decided to hide that suffix in the UI and API responses, so a user would keep seeing all over the same system_name chosen by the creation of the metric. This second decision may have put us into trouble, itself or on the way we implemented it. Sometimes where the "extended system name" (with the backend ID suffix) is needed we are still using the "clean" system name (without the suffix), e.g. stats.
We need to rethink that design.
Solution is to simply not to hide the suffix. We append it because it's a technical requirement and let the user know it exists. That is probably the easiest solution.
Rejected idea because it continues with the idea of hiding stuff from the users and we want to move away from that.
Another idea goes in the direction of a more sophisticated implementation for hiding the suffix, using Ruby refinements. Not doing it this way because it is complicated and hiding vital information like system_name is not the good way to go
- is related to
-
THREESCALE-4013 Internal Error when disabling method at backend level
- Closed
- relates to
-
THREESCALE-4382 Error viewing application details after adding limit
- Closed
-
THREESCALE-4761 Make it clear for users that the system name of metrics and methods will get a suffix they don't control
- Closed