Hoppa till huvudinnehållet

Hide add feature and edit buttons for users without permissions

Kommentarer

8 kommentarer

  • Phil MacIntyre

    Hi Max,

    Thank you for your question. We chased this issue down and confirmed there's an underlying Esri bug which is preventing the permissions check from behaving appropriately. We've reported it to them, so hopefully a fix will come from their side before long.

    In the interim, we've added in a warning message. If a user tries to submit an add/edit on a layer for which they don't have sufficient permissions, they'll get that warning and we'll clear the graphics so they won't be under the assumption that the save was complete. Hopefully this will be sufficient until we can implement a more complete solution once Esri remedies their side of the issue. This fix will be included in our upcoming 5.20 release, slated to be available in late October.

    Any other questions please let us know,

    Phil MacIntyre

    0
  • Max Molello

    Hi Phil,

    We are on 5.21 now and I remembered about this fix and went to test it, but it still seems to work the same as before. The edit seems to save as normal with no error or message for Viewer roles. No data is actually saved though and when the app is refreshed the edits are gone.

    Were the changes you referred to only applied to Workflows and not the default editing tools in the Mobile?Thanks

    0
  • Phil MacIntyre

    Hi Max,

    Thank you for reporting this. The functionality should be in the default editing tools. Let me take a look into this and get back to you ASAP.

    Cheers,

    Phil

    0
  • Phil MacIntyre

    Hi again Max,

    I fired up our 5.21 store builds on all 3 platforms and I did get the expected behaviour as described above. Unfortunately due to an Esri Runtime limitation, we are unable to totally omit the inaccessible layers from the add feature layer list, but once an add/edit is attempted to be saved we will pop an alert informing the user of their insufficient permissions and returning them to the form. Like so:

    That's with our default, out of the box add/edit feature tools.

    I tested with a viewer user with features that were only shared at the org level (in which case they were blocked by the above alert), and then again with features that were shared publicly (in which case they were allowed to add/edit).

    Could you please double check your version of Go, as well as your layers' sharing permissions? We can troubleshoot further from there.

    Thanks!

    Phil

    0
  • Max Molello

    Hi Phil,

    That doesn't seem to work on existing apps or even a newly create app using an existing portal map and layer. Here is my setup tested while trying to edit a text field in an existing point feature.

    • User is a Portal Viewer/Viewer
    • The production portal map, app, and map feature layer service are shared to Organization and viewable by all Org members. I have not tried with items shared to Public since we don't use those.
    • I've updated the app in SaaS VertiGIS Mobile designer 5.21
    • Tested in Windows 10 and Android 13 VertiGIS Studio Go 5.21.0.360

    When I try to add a new feature or edit an existing one it appears to save, but obviously nothing is actually changed. When the app is reloaded those changes revert back to the actual data. There is no popup or warning like you showed above. Editing the same point and attribute as user with editing privileges works as intended.

    We did have a problem a while back with publishing existing apps not working as it should after a VertiGIS update but it was fixed after making a whole new app. Since this also still doesn't seem to work with a new app maybe it's something else.

    Thanks for looking into it with me.

    0
  • Phil MacIntyre

    Hi Max,

    I've managed to reproduce this with some of our own data using one of our Portals. It appears to be a difference between how Viewer users are handled in Portal vs. AGOL. Our team is looking into it as we speak. Which version of Portal are you using, so we can be sure to test against that when we figure out a solution?

    Thanks,

    Phil

    0
  • Max Molello

    Good thought, I sort of forget that a lot of people use AGOL sometimes. We are on Portal and Server 10.9.1

    1
  • Phil MacIntyre

    Hi again Max,

    Thank you for your patience with this. We have adjusted our fix to work with both AGOL and Portal, and Go should now display the warning alert if a Viewer-level user attempts to add, edit, or delete a feature they don't have permissions for. This will be included in our upcoming 5.22 release.

    Have a great day!

    Phil

    0

Du måste logga in om du vill lämna en kommentar.