WFS-T editing for MapStore users

[Emil Ehnström]

Hi,

I have a scenario where we are using MapStore and want to edit data using WFS-T (coming from GeoServer). I read this discussion which is closely related, but my question is a bit more general.

What would be the recommended approach for giving MapStore users (non-admin) rights to edit a WFS-T layer? I've understood that it's not possible by default in MapStore, but with an integration with GeoServer roles this could be achieved? LDAP is not an option in my case.

Kind regards,

Emil Ehnström

[Lorenzo Natali]

Hi,

This is technically possible, and with the standard MapStore/GeoServer integration or LDAP the concepts are the same.

It requires the admin to handle the maps and the layer permissions accordingly on both GeoServer and MapStore. 

If you allow the users to edit from the feature table a certain layer but GeoServer do not provide the access, when the user try to save, the saving will be denied.

In fact GeoServer is not able to show the permissions on the Layers to MapStore, so is up to the admin to prepare the UI accordingly in sync.

There are various strategies to accomplish this, playing with:

- map permissions

- context configurations

- map configruations

done in sync with GeoServer's permission.

Usually: 

- The admin of GeoServer can give some users the editing permission to the layers on GeoServer, via GeoServer security or GeoFence (MapStore has a support also for Geofence management directly in UI in the case).

- Then as admin in MapStore you can allow certain groups/roles to use the eding functionality for the Attribute Table (properties editingAllowedGroups/editingAllowedRoles). This can be configured 

    - in localConfig.json (So the configuration is used in the default viewer for the maps) 

    - or in a context that you decide to use for certain maps.

- then the admin can also decide, map by map, to enable/disable the editing tool for certain layers, from layer properties. 

Using this tools, and depending on your organization, you can handle the write permissions.

For instance certain organization has some groups that can edit everything, and so it is sufficient to set the `editingAllowedGroups` as default is localConfig.json and in any context (using pluginsConfig.json to set the default for new contexts).

Some other organizations has a more fine grained permission system, so in this case the administrator can configure maps/contexts dedicated to the editing, shared with the proper users.

I hope I gave you some possibilities that you can try to adapt to  your use case.