Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include editing support to allowed user groups #9179

Closed
6 tasks done
tdipisa opened this issue May 17, 2023 · 2 comments · Fixed by #9210
Closed
6 tasks done

Include editing support to allowed user groups #9179

tdipisa opened this issue May 17, 2023 · 2 comments · Fixed by #9210

Comments

@tdipisa
Copy link
Member

tdipisa commented May 17, 2023

Description

As discussed and agreed with #7636 it is required to allow certain editing functionalities depending on the groups the user belongs to.
At the moment the editingAllowedRoles configuration property is available for FeatureEditor and StyleEditor tools to allow users to use the editing functionality depending on their role (ADMIN or USER) by disabling the pencil icon if the user belongs to a role not granted.

It is necessary to extend this system to allow editing functions to users also according to the groups they belong to.

Acceptance criteria

  • The support for a new configuration property named editingAllowedGroups will be included

  • That new property can work together with the existing one. For example:

    "editingAllowedRoles": [
          "ADMIN",
          "USERS"
     ],
    "editingAllowedGroups": [
          "Group 1",
          "Group 2",
          "Group 3",
          ...
     ],
    
  • That new property will be supported everywhere the existing editingAllowedRoles is managed in the MS code base (that means for both FeatureEditor and StyleEditor)

  • Both properties should be probably prioritized somehow to properly catch special cases. For example an ADMIN user should be always allowed independently of the group he belongs to. Therefore editingAllowedGroups should be applied only to users with USER role

  • The editing functionality of the Attribute Table (plugins.FeatureEditor) can be reached also from the Identify tool if its cfg.showEdit property is set to true. That case should be managed accordingly (eg. the pencil icon in Identify panel not available) according the role/group permission rules defined for the plugins.FeatureEditor tool (there is already a control in the Identify plugin to check, looking at the Attribute Table state, if the user is allowed or not)

  • If the Disable editing with Attribute Table property is set to True for a layer the editing function in Attribute Table will be disabled at all independently of the value editingAllowedRoles and editingAllowedGroups. ADMIN users can do everything as usual anyway

Other useful information

See also #9180

@dsuren1
Copy link
Contributor

dsuren1 commented Jun 5, 2023

If the Disable editing with Attribute Table property is set to True for a layer the editing function in Attribute Table will be disabled at all independently of the value editingAllowedRoles and editingAllowedGroups. ADMIN users can do everything as usual anyway

Will be applicable when #9180 is implemented

@dsuren1
Copy link
Contributor

dsuren1 commented Jun 6, 2023

Updates

  1. Default value for editingAllowedRoles: ['ADMIN'] and editingAllowedGroups: []
  2. User is allowed to edit, if they belong to one of the roles or groups configured
  3. Support for 'ALL' roles. Takes highest precedence and allows all users regardless of the role or group the user is

tdipisa pushed a commit that referenced this issue Jun 7, 2023
* #9179: Include editing support to allowed user groups

* Code refactor

* Unit tests corrected

* Permission hierarchy updated
@ElenaGallo ElenaGallo self-assigned this Jun 7, 2023
offtherailz pushed a commit that referenced this issue Jun 21, 2023
* Code refactor

* Unit tests corrected

* Permission hierarchy updated
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants