groups and roles feature

[TobiasNickel]

Do you think it would fit into the scope of pocketbase to have some kind of roles or groups for users? it would be cool if such information could be used within the collections access rules.

it could be to have a role and user_role table.

or just give users a customizable field that is available within access rules, can bring us a long way.

what is your opinion?

[ganigeorgiev]

This should be already supported. You can add custom user field "role" and use it in your access rules. For example:

// allowing only authenticated users with role="manager"
@request.user.profile.role = 'manager'

You can even allow one user to edit another user's profile data (eg. as in manager-subordinate relation).

This is already mentioned in the Manage users guide.

[ganigeorgiev]

@edgarasben No, the API rules apply only for regular users.

Only admins have access to the admin dashboard. In PocketBase all admins act as "super-admins" - they can access and modify everything, including other admins.

[edgarasben]

@ganigeorgiev I see. This is one of the biggest issues currently for me working with Supabase. I would like to be able to have content editors (other people) managing a database/users etc. but restricted to certain tables and certain actions.

It that would work, then basically this could act also as a CMS system.

[perfalle]

How can I stop users from editing their own role but still grant them access to e.g. change their profile pictures?

[ganigeorgiev]

@perfalle Assuming that the role field is required, you could prevent profiles role field update by comparing the submitted value to the original, eg:

role = @request.data.role

For more advanced data validations, you can make use of the OnRecordBeforeUpdateRequest event hook.

[geoHeil]

it works well with directus. (content editor role) but I would love to see something similar in pocketbase

[osseonews]

Is the roles for admin, so everyone admin is not a "super-admin" on the roadmap? For me also this is the biggest issue with pocketbase and the one thing I see as truly missing. It's rare that there will only be one individual using the admin dashboard, and even rarer that each admin can be a super-admin.

[ganigeorgiev]

I may consider working on admin roles and api keys in the futures, but for now this is not planned.

PocketBase Admin UI wasn't really intended to be used as CMS. I created it for data exploration and to be used as a developer tool, similar to the Firebase Console UI.

Even if we add admin roles it will be always limited compared to the other existing headless CMS solutions and the main idea is to use PocketBase as core and build on top of it. You could also check this discussion - #50

[osseonews]

Thanks. You may not have intended the Admin UI to be used a CMS, but it is perfectly designed for that. It is amazing in its simplicity and ease of use. I don't think the admin roles need to be too complex to get it to work for a team, where not everyone is a super admin. Traditional headless CMS are in fact too complex, which is exactly why I was interested in Pocketbase. Of course, I can build a CMS on top of Pocketbase (I was considering using React-Admin for this), but then I would defeat the purpose of Pocketbase, as with the amount of work involved to create the CMS on top of Pocketbase, I could just stick to an existing headless CMS.

You see the problem you have solved (even if you may not have intended to) is that existing headless CMS have become too complex, too costly, and have too much lock-in. At the same time, if you build a CMS on a database like Postgres using a tool like Hasura, you have to then build an entire frontend interface to manage everything, which is a massive waste of time and energy. With Pocketbase, the amazing thing is that everything is done for you out of the box with one executable. No complexity, easily portable, no lock in, easy way to edit the underlying data. So it solves all the headaches. Well, except for one: all admins are superadmins :0)

[edgarasben]

It doesn't necessarily has to be compared to other CMS. I think it should be compared more to Airtable. We and many other smaller startups use it as a database, but also as a nice interface for managing content. Even non-tech people can use it. And it acts as a CMS in many cases. And I love Airtable (or Notion databases) over many other CMS systems. It's faster because basically the tables are like sheets.

Supabase didn't nail the table editing experience yet (e.g. you can select and delete/paste data to multiple rows by selecting) and they don't have the editor roles/permissions either.

[ifigueroap]

I just ran into the issue of wanting to provide access to the admin dashboard, but only with permission to add/update data in certain collections. It would be a great addition, as it avoids the need to implement a similar CRUD in, e.g. React-Admin.

[mugen6]

@osseonews you said it perfectly. I love the simple interface, it's so clean and fast. I've used commercial CMBD tools that take 3-4 seconds to load a page and they just feel bloated.

Pocketbase is almost perfect for our small team to store configuration data (2 super-admins, 1 power user and 1 non-technical user) and it would be extremely helpful to change read/write permissions of collections for each user. We could ask another team in our business to create a front end, but what a hassle with too many people getting involved for a simple internal tool.

The UI is so nice, it's tempting to see if we can fork Pocketbase and just modify the UI component, so that we can still sync with upstream without too much friction. It's either that or start looking at no-code options like Budibase/Appsmith/Tooljet.

[tecnicosya]

Hi. I'm interested in the fork. How about is the progress?
I see OpenXava and have automatically web interface based on Java classes and have granular control access, but in paid version

[jonshipman]

Might be easier to just rewrite the Admin UI in whatever stack you currently have. It's just a simple table.