Can the Fibery app builder AI check the logged user's database permissions and act accordingly?

Get Help
1

I have Entity type Foo, which is visible to all users, but only editable by specific user groups, OR to direct assignees.

In a custom app, I’ve made an edit wrapper around Foo which gives users a very easy method to update it without missing important fields, essentially building around the restrictions of Fibery to enforce proper workflow.

The issue I am facing

  1. A user navigates to a Foo entity they do not have edit privileges on.
  • They are presented with the edit wrapper.
  • They can access the fields.
  1. They make changes and attempt to save.
  2. The save is fired, but Fibery prevents the update natively through regular permissions checking at write time.
  3. My app shows a toast about the failure and an error on the field they tried to change.

My contention with this behaviour is that they shouldn’t have gotten to this stage to begin with. The page should be entered in a view mode.

However, I cannot find for the life of me how to check their access level before the navigation. I can easily wrap each component in mode-checking conditional set-outs, but there’s apparently nothing to check.

The AI also doesn’t know how to do this aside from “probing” (attempting a write as the user) before serving up the entity, which it states causes “possible side effects” (one I know definitely is that the “modified at” date will change).

So my questions:

  1. Is entity/database access exposed anywhere in the backend for custom app development? and if not
  2. Is this on the cards for future releases? and if not
  3. How can I achieve this without essentially mirroring the database access logic into code? (creating a maintenance nightmare if any access changes)
2

I don’t have an official answer to Q1/Q2, but I’ve run into the same thing building custom apps for our workspace. The pattern that’s worked for us is to drive everything off Teams instead of individual permissions.

Each space grants access through Teams only, never to individual users. The custom apps then read the current user’s Team membership and use those for any gating mechanisms: Team A gets the edit view, Team B gets read-only, and so on. Adding or removing someone is a single change in Fibery. Put them in the Team and their space access and app permissions update together, with nothing to change in code.

The one thing to watch: the app decides what each Team can do on its own, separately from Fibery. If you change a Team’s access in the space settings (say, from editor to viewer), you’ll need to make the same change in the app. Naming each Team after its role, like “Foo Editors,” makes it easier to track.

For your “OR direct assignees” case, I’d add an assignee check alongside it: query Foo’s assignee field, and if the current user is in it, open in edit mode. Since that’s just reading data, it never drifts from what Fibery enforces.

Fair warning: moving from individual permissions to Teams takes some upfront work, especially if your spaces have built up a lot of one-off access over time. It’s paid off for us, though. We now have a small team management app for adding and removing people from Teams, so access changes take seconds and nobody has to dig through space settings.

3

Hello.

Thanks for your question.

Currently custom app has no direct way to check user permissions.

We are slowly supporting more and more fibery apis in custom app platform, so an agent knows what is possible. Right now we are working on Automation Buttons support, next is a history api.

I’ve created a Feature Request for permissions api. Looks like an absolutely reasonable request. So an agent will know that databases and entities in Fibery have permissions, and it can check permissions while rendering view/edit mode.