Drawers only open for Admins - not standard users

I have a table with a drawer. Inside the drawer is a table with child records. (Parent is a Quote Line, children are the Approval records, for context.)

If I click the Drawer row action button as myself,* it works perfectly: opens the drawer and displays the table. The same is true when I use the “Open All Drawers” button I built using a Component Action tied to the table.

*Confirmed it works the same when logged in as another Admin.

The strange behavior is when logged in as anyone else - the drawer icon flips (I’m using a caret, so it turns when the drawer is opened). But there is no drawer - nothing changes other than the icon. It’s not as though the drawer opens, shows the table, but the data is missing. (Users can see this same list of Approval records in traditional Salesforce pages, so I don’t think it’s a records/permission issue.)

It’s as though the drawer itself is locked and refuses to open for everyone else. I don’t have any render or enable conditions on any of these functions, so I’m a bit flummoxed.

Screenshots for reference. Halp!

Hi Monica - I definitely think it sounded like a permissions issue as well, but here are some additional things you can check.

  1. Display logic (rendering conditions) for the table in the door
  2. When you view the page as a non-admin, are seeing any errors in the browser console?
  3. Actions that are running when the drawer opens
  4. Double check security settings for all objects and fields used in those actions and the component(s) in the drawers
  5. Another thing you can do is take out different elements in the drawer (fields, for example) and see if one of them is causing the issue.

For general troubleshooting tips as well as how to open the browser console, check out the Skuid Troubleshooting Toolkit course in Skuid Skool.

:tickets: If you’re a support customer, I recommend opening a ticket for this if you’d like a second set of eyes.

Thanks Anna!

It’s very strange…

image001.jpg

I’ll add some other thoughts.

Try to isolate whether it is the drawer not opening, or the underlying model not querying.

Add some other component to the drawer (like a text block) that is completely independent of the second model. Does it show?

  • If not - we need to study how permissions are affecting the drawer opening.
  • If it does - but the table doesn’t show - Im going to suggest that the user doesn’t have some access to its data…

DO you have some context condition on the table that uses a field the user doesn’t have access to?

What Version of Skuid is being run here?

So many mysteries…

Weird! I used “reply” in the email that I got …and it snipped the bulk of my answer! :woman_facepalming: Maybe it didn’t like my numbered list.

Here was how I (tried to) respond to Anna -

  1. No display logic on the drawer button, nor on the table. The drawer icon appears for the other users, it just … doesn’t do anything.
  2. There were some errors, regarding some fields on the Quote Line (the model driving the table). However, after I removed them from the page, drawer behavior doesn’t change.

a. Related to this - do you know if Skuid has any plans to change how it handles fields that are in the page, where the running user doesn’t have permission to see them (due to their Profile).
b. Example: I have about half a dozen fields that Sales users shouldn’t see. In regular Salesforce pages, if they are on the page, it’s not a problem – Salesforce just hides them. But Skuid throws up a big error on the page, saying “can’t find these fields”.
c. I’ve had to create 2 separate Skuid pages now, because I have to properly remove the “can’t find” fields from the data models…instead of just allowing permissions to take care of it.

  1. The only action is to query the data model driving the table inside of the drawer.
  2. Security settings are good – the users can see the data in normal Salesforce pages.
  3. I removed the table in the drawer entirely. Replace it with just a text component. The drawer still doesn’t open.

a. I also removed the query (mentioned in #3), still no dice.

A few thoughts.

  1. Errors about field permissions have typically only been shown to users that have the “skuid builder” permission set. So you should be able to roll out pages to normal users where there are fields they don’t have access, and if they have the “skuid user” permission set - they will be none the wiser. Tell me if this is not working as designed.

  2. What version of Skuid are you running? And how is page being accessed in Salesforce. (VF? Lightning component? Etc)

  3. How customized is the profile / permission set arrangement of the user that can’t open the drawer? Is there any permission that strikes you as likely reason the page doesn’t work for them

1 Like
  1. Hm. I hadn’t done any permission sets, so was hoping this would work! But I added the “skuid page viewer” to this user…and he still gets the error on the page with all the hidden fields.

  2. We’re on 16.2.6
    The page is in a Skuid LWC component in a Lightning page.

  3. All users are on the same profile. The hidden fields are not part of the Profile; then they’re including in a Permission Set I give specific users.

The drawer thing is mind-boggling…because even when I take the table out and put in a text box, it still doesn’t open.

Those fields are the only thing different between the two groups of users - though I also have display logic on certain things. But none on that drawer, nor its contents. I’ve even rebuilt this page from scratch (for other reasons) in the last couple weeks, and the drawer still doesn’t open. Just tried it with a User who has that extra permset, just in case; no luck. I even logged in as someone in a different division whose profile has no such restrictions…still get the same caret-toggle, no drawer.

Hi Monica, happy new year and apologies for the delayed response.

Because of the complexities here, I’d recommend you open a support ticket and grant Skuid login access to your environment so the team can see what you’re seeing and assist you further. In the ticket include your Salesforce org Id, a link to the affected page, and a link to this post so they can see what we’ve discussed already.

Take care.