Users with User role from at least one organization received an access denied message when trying to modify the environments of a root (at 23-08-30 16:21 to UTC-05 23-09-20 15:52 21.9 days -time to recover-). The incident was detected reactively (at UTC-5 23-09-19 10:01 19.7 days -time to det-) by a user who reported through our help desk [1] that when trying to add an APK file to an environment he was shown an Access denied message.
In the Environments tab, a query was made asking for some data to which the User role did not have access, so the Access Denied message was displayed.
From this error, we realized that there was also an outdated/mismatch between the permissions assigned to the role and what the business had defined that the role could actually do.
Solution
The permissions assigned to the User role were defined, and it was established through architecture that this role would not be able to modify roots [2], so now they will not be able to view the roots editing modal as they could previously and therefore the environments editing tab that generated the error will not appear.
The error was generated by a deficiency in the definition of the permissions assigned to the User role, receiving the Access denied message was normal considering that in principle the users with this role should have been denied access to the Roots edition panel. LACK_OF_PLANNING