Add CONTRIBUTOR functional role to filter FeatureEditor visibility

[jusabatier]

Description

Add a 'CONTRIBUTOR' functional role, that can be used to limit FeatureEditor visibility to specific users.
Actually we have to choose between 'ADMINISTRATOR' or 'USER'.

The aim is that in the Georchestra's fork, we can assign a role to be 'CONTRIBUTOR' and have the editing tools, but keep it masked for simple users.

What kind of improvement you want to add? (check one with "x", remove the others)

• [ x ] Minor changes to existing features
• [ x ] Refactoring (no functional changes, no api changes)

[jusabatier]

For this, @tdipisa explain us that there are 2 possibilities :

• To make things simple and less impacting the existing codebase the goal could be to simply include a new role with effectivelly the same rights of USER as far as the model is concerned but that can be used at plugin configuration level to assign more rights on UI components.

• An alternative way could be to manage these aspects using MS groups. The current support could be enhanced to support also groups so that a dedicated group can be created for the purpose and the plugin configured accordingly. This is probably the better solution more in line with the current model.

I think the first answers the issue and is simple, but not flexible as it only apply for the edition tool.

I don't understand well the second one, specially in the mapstore2-georchestra's context :

• Mapstore's groups you mention are equivalent to georchestra's roles ?
• If true, does this solution implies that we can use georchestra's roles for enabling edition instead of mapstore's ADMIN/USER ?

[tdipisa]

@jusabatier

If true, does this solution implies that we can use georchestra's roles for enabling edition instead of mapstore's ADMIN/USER ?

Yes, that's the idea.

[tdipisa]

An alternative way could be to manage these aspects using MS groups. The current support could be enhanced to support also groups so that a dedicated group can be created for the purpose and the plugin configured accordingly. This is probably the better solution more in line with the current model.

The second option is what we will implement

[catmorales]

Sorry, something is not clear for me and I need more informations

Edition tools are configured in two ways :
1- In the plugin Feature Editor
We define who is allowed to edit layers

 "editingAllowedRoles": [
      "ADMIN",
      "USER",
    ],

Now, just this two MS Roles can be used, as in our geoserver, USER rôle is applied for all people connected and for all layers, Every user connected on the application context for every layer in the map, see the Edition button:

2- In the plugin Identifier
We define if the button is visible or not "showEdit": true
eg:

{
  "cfg": {
    "showHighlightFeatureButton": true,
    "viewerOptions": {
      "container": "{context.ReactSwipe}" 
    },
    "showEdit": true
  },
  "override": {
    "Toolbar": {
      "position": 11
    }
  }
}

After this improvement (the last option) I understood that geOrchestra Roles will be maped with the MS Contributor group.
I suppose we will add a geOrchestra Role instead of "USER" to restrict the ability to edit all the layers at this Rôle .

Where the mapping beetwen geOrchestra's Role and Contributor MS group will be done?

1- Feature Editor plugin
I suppose we will be able to configure Feature Editor as:

"cfg": {
   "editingAllowedRoles": [
     "ADMIN",
     "EL_MAJ_INTERCO" 
   ],

So the impact will be:

• just users having the EL_MAJ_INTERCO or ADMIN rôles can see the edition tools
• the same for each layer if layers to edit are configured with rules on this geOrchestra's Role in geoserver ? (completed with [FeatureEditor] Allow to provide editable layers list #7285)
  eg:
  espub_mob.aire_jeu_jeu.w | ROLE_EL_MAJ_INTERCO

2- Identify plugin
Will the behaviour of this plugin be the same (it shoud be) ?

@tdipisa thank you to confirm my understanding (or not) ;)

[tdipisa]

@catmorales

After this improvement (the last option) I understood that geOrchestra Roles will be maped with the MS Contributor group.
I suppose we will add a geOrchestra Role instead of "USER" to restrict the ability to edit all the layers at this Rôle .

Where the mapping beetwen geOrchestra's Role and Contributor MS group will be done?

There will not be any special mapping here. Simply, you will have the possibility to use MS groups in the editingAllowedRoles and not only the usual MS roles (ADMIN, USER).

I suppose we will be able to configure Feature Editor as:

"cfg": {
   "editingAllowedRoles": [
     "ADMIN",
     "EL_MAJ_INTERCO" 
   ],

So, yes, something like that. Maybe the name of this property (editingAllowedRoles) will change or we will ad a new one dedicated to groups, I'm not sure now, let's see.

the same for each layer if layers to edit are configured with rules on this geOrchestra's Role in geoserver ? (completed with #7285)

That's a bit different. As I have specified here: only admins or who has edit permission of the map/context can control that from Layer Settings.

2- Identify plugin
Will the behaviour of this plugin be the same (it shoud be) ?

Yes. There is already a control in the Identify plugin to check, looking at the Attribute Table state, if the user is allowed or not.

[catmorales]

Thank you so much for your answer !

[catmorales]

@tdipisa
Another question /precision on this topic.
We need be abble to configure various georchestra's Rôles as contributor (not only one) .
eg : EL_MAJ*
We have , now 7 geOrchestra's roles allowed to update WFS-T services . Each one is used in distinct application context or application (QGIS).
But we can imagine a use case where on the same application context we will give the rights to edit layers at two our more geOrchestra's roles.

This use case will be treated in the developments you will done?

[tdipisa]

@catmorales yes. As you can see from my comment above I've specified MS groups : also the current editingAllowedRoles supports an array of possible values and the logic will be the same.

[dsuren1]

Note:
FYI
We intend not to combine roles and groups into editingAllowedRoles. Instead we will introduce a new configuration property called editingAllowedGroups so roles and groups are configured separately and can be easily distinguishable

[tdipisa]

Closed in favor of #9179