Adminpannel I like users to update their email but not their role

[rodezee]

I have setup users to be able to update their own data:
This works fantastic, but now the users can also update their own "role" and make themselves "admin".
Is there a way to prohibit users form changing the field "role" but still let them change their email?

[jonaspm]

It comes to my mind the use of a before update mutation event, where you can remove/ignore the fields you choose.

Something like this:

  app.emgr.onEvent(
    DatabaseEvents.MutatorUpdateBefore,
    async (event) => {
      const { entity, data } = event.params;
      switch (entity.name) {
        case "users": {

          // Set role to user
          data.role = "user";
          // Remove role from update
          delete data.role;

          break;
        }
      }
    },
    { mode: "sync" },
  );

[rodezee]

This is amazing, thank you for the quick response!
Right now it runs always, is there a way to only run it when the logged-in-user has the role "user"?

[jonaspm]

I think there is, never tried that though, you might be able to access the current logged in user without executing an explicit query then do a conditional logic.

[rodezee]

That sounds good, is there a global variable $Context where i can tap $Context.user.role from?

[rodezee]

OK, I have tried the whole day, but I just can not get to user.role, rather with request events.
I would like to adjust the source code to add a "context" variable to the Database events, this is very usefull in my case and maybe for others too. What do you think?

[jonaspm]

Seems that there is no way to get the current user from within an event, the current architecture is limited in that regard.

@dswbx @cameronapak this is a common use case that could be solved by adding that context @rodezee mentions. I think it is a good time to start the discussion on how to enable this.

After some brainstorm with the AI, this was its stance on the final recommendation:

For bknd itself, I’d implement:

1. Mutation payload context in data permissions
2. Field-aware policy evaluation
3. Keep auth-based column restrictions in the guard/permission layer
4. Only later consider auth propagation into mutator events

That gives bknd a clean way to support:

• row-level permissions
• field-level permissions
• auth-aware update restrictions

without overloading mutator events with HTTP request concerns.

If you want, I can turn this into a concrete implementation plan with exact changes to:

• bknd/app/src/data/permissions/index.ts
• bknd/app/src/data/api/DataController.ts
• and the minimal object-query addition needed for `fields contains "role"

[rodezee]

YES let's do this!

To be sure what you mean by "Mutation payload context in data permissions" & "Field-aware policy evaluation"

Is it like this:

[jonaspm]

YES let's do this!

To be sure what you mean by "Mutation payload context in data permissions" & "Field-aware policy evaluation"

Is it like this:

That is correct 😄

[rodezee]

If you want, I can turn this into a concrete implementation plan with exact changes to:

* `bknd/app/src/data/permissions/index.ts`

* `bknd/app/src/data/api/DataController.ts`

* and the minimal object-query addition needed for `fields contains "role"

can you do this plan, so I can try my best typescript.. :), to help you implement this?

[jonaspm]

If you want, I can turn this into a concrete implementation plan with exact changes to:

* `bknd/app/src/data/permissions/index.ts`

* `bknd/app/src/data/api/DataController.ts`

* and the minimal object-query addition needed for `fields contains "role"

can you do this plan, so I can try my best typescript.. :), to help you implement this?

sure! please join the rest of the community on Discord: https://discord.gg/YCsGnbs6c
lets continue discussion there.

regards!