SRA>System Settings>Invite user: SRA able to invite a user to be a RM, RC or API consumet

[SteeveEbener]

• CGR version: 0.7.0

Describe the bug (clear and concise) A SRA can invite someone to be a RM, RC or API Consumer for a specific GeoObject Type

To Reproduce As a RA:

1. Create a GeoObject type
2. Log out

As a SRA:

1. Go to system settings
2. Click on Invite User
3. See error: you can invite a user to be a RC, RM or API consumer for GeoObject type you have created:

Expected behavior (clear and concise) A SRA should only be able to invite someone to be a RA, not to invite someone to be a RM, RC or API Consumer for a specific GeoObject Type

Screenshots See above

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Google chrome
• Version: 81.0.4044.129 (Official Build) (64-bit)

Additional context (if any)

[justinlewis]

While the expected behavior outlined here describes the expected behavior of an SRA the currently implemented functionality does not prohibit them from performing their duties. Right now the system allows an SRA to be a fallback if all the other RA's are not able to make a change. I'm going to deprioritize this for these reasons given other priorities.

[SteeveEbener]

No problem with the prioritization level.

I just want to mention that the SRA represent a governance mechanism over the CGR platform and is therefore under the authority of a different "organization" than the organizations managing the content and the users having a role on such content.

As such, it is important for the organizations in question to continue managing their roles and content without such a level of interference from the SRA level. The SRA should basically not be able to see who are the RM or RC of a given organization.

[nmceachen]

@SteeveEbener, I understand. A concern I have is that, should an organization's RA become unavailable, a support request for account management would need to be escalated to the SRA. Once the CGR is established then I think it makes sense to disable the ability for the SRA to perform account administration for an organization, but practically as this is rolled out to an initial implementation where multiple organizations are not important, then having two separate administration accounts to perform admin tasks like any other system adds another step of complexity. We would be committing to adding additional complexity when, it sounds like, Laos may not need it.

[SteeveEbener]

Thinking that multiple organization is not important at this stage is a mistake which might lead to important problems at a later stage.

It is the Organization function to take care of the RA level and to ask the SRA to act on a given RA account in case this is needed (e.g. RA user that has left without given his account password). For the rest, the organization should take care. => there is no need for two separated accounts.

[justinlewis]

It was agreed on June 1, 2020 by @justinlewis, @steeveebener, and @nmceachen that the SRA abilities must be limited to high level administration such as creating organizations and assining RA's to Organizations. See the user roles matrix for a comprehensive outline.

[justinlewis]

Marking as invalid and closing because SRA has been depricated in favor of System Admin while the need and organizational implementation for SRA is evaluated.