Expand all | Collapse all

Role permissions for pages

  • 1.  Role permissions for pages

    Posted 07-02-2019 20:10
    I've set up an app with a dashboard page that is open to EOTI. The purpose is for the public to see upcoming events, and register for them. It was all working great, until I realized that typing in ?a=showpage&pageid=X (where X= the page ID of the admin page) to the end of the URL allows them to access the dashboard page that was created for app administrators.

    Since a hover on other parts of the app will show the basic schema of how to access the page, all it would take is replacing the pageID with the ID of the admin page for them to see the admin page.

    Is there a way to restrict access to pages in the app for EOTI based on role or user settings? I'm worried that somebody could potentially view reports or records they shouldn't by modifying the URL in the address bar.

  • 2.  RE: Role permissions for pages

    Posted 07-02-2019 21:15
    While it is true that they can go to those pages(I didn't know that until just now) they should not be able to see any data there. I tested this just now and I could go to the admin or any other page as the lowest role in my org but every page displayed nothing in the reports and some even said access denied.

    If the report is displaying information to them then that is another issue. You should set the permissions for that EOTI role to be VERY restrictive in what tables and things they can see. If you have a table you do not want them to get info from make sure they are set to not be able to view, edit, or add to that table and if you want to go the extra mile you can make sure that is set at the field level as well. You can do that where some fields are allowed and some are not but safer way is to deny all. Only give them access to exactly the table they need and nothing else.

  • 3.  RE: Role permissions for pages

    Posted 07-02-2019 21:29
    How you described it above is how it works, but in the table listing the events I have a summary field of how many people have registered for the event. That summary count gets passed back to the registrant table to display on the form when someone registers, in order to calculate how many open slots for the event are available.

    When the app was first set up, I had to allow view of All Records on the Roles>Permissions tab for the table in order to get that feedback of how many slots are left to work. I figured since there was no way that I knew of at the time for the users to access that table (hiding table buttons, links, etc), it would be okay, until I found the url editing trick. All the reports for the registrant table have been restricted, but table access granted so the summary field on the events table can work right for the EOTI role. 

    Since access to the report displaying on the admin page doesn't show up in the table reports widget, for now I've replaced the report showing all registrants with a different report that doesn't show everybody's information. This works, but makes the admin have to do a couple more clicks to get to that report that originally was on the main dashboard page. Good enough for now, but Austin if you or anyone has any additional suggestions I'd love to hear them!

    Thanks for the help!

    [edit] I also discovered now that if EOTI has table access the url address bar can be edited to access any of the reports for the table.

  • 4.  RE: Role permissions for pages

    Posted 07-02-2019 23:38
    For posterity's sake, or for anyone with the same problem, or future me when I have the same problem and come to search here for the solution, here's what worked:

    Deny access to the registrants table for EOTI, except the ability to Add a record. Create a plain numeric field on the events table that gets updated via automation when a new registrant is added.

    What was happening was the formula field used to calculate remaining open slots for the event used the summary field number based off counting the registrants, then that remaining open slots number was passed back down to the registrant table to display on the form as they filled it out. Having a plain numeric field on the event table update via automation when a new registrant is added to the related event, then passing that plain number back down to the registrant table worked, and I was able to completely block off access to the registrant table for EOTI, since a summary field no longer needed to "see" how many others had registered for that event, and thus no longer required the registrant role to have access to the table.

    Also, an EOTI manually editing the url bar to show specific reports no longer works because table access was able to be denied for EOTI, and the List All of registrants report was placed back on the admin page. An EOTI can still get to the admin dashboard page by manually typing in the URL, but can see no report links or embedded reports they shouldn't.