Column level access control? #1571
-
|
I have a couple different scenarios that require specific columns on a table have different access permissions. Scenario 1: I have a table which contains a timestamp (start_at). I want to have some columns unable to be read/visible until the start_at time has passed. (The whole table is read only and only editable by admins, I just want some columns hidden until appropriate). Scenario 2: I have a table which is editable but some columns are supposed to be read-only and updated by admins. This seems to boil down to the concept of column level rules? I am using pocketbase as a framework so I am willing to write custom code if needed. I just want to double check this isn't already possible (based on my searching I don't think it is?) |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 9 replies
-
|
There are no dedicated field/column level access/visibility rules. You'll have to implement it on your own depending on your use case. At the moment the easiest way to hide/restrict access to fields is to move them to a new collection with their own API rules. This eventually will be simplified in the future, since there are plans to add a "view" collection type per #311 (comment). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply @ganigeorgiev. So for the first scenario I listed would the suggested approach be to alter the response using record api hooks to remove certain columns if the start_at time is future? Or would you suggest having the conditional visibility fields in a separate table and control the access with a rule that compares |
Beta Was this translation helpful? Give feedback.
-
|
It depends on your use case. Usually, there are 3 common options:
Personally, I'd go with the first option. |
Beta Was this translation helpful? Give feedback.
-
|
I have a couple of scenarios that I think are related, but don't require any computation so I'm not sure if these are currently possible:
I wasn't sure if #311 would solve these types of scenarios. Thank you! |
Beta Was this translation helpful? Give feedback.
-
The Isset operator might not be optimal in cases where some webapps send the unmodified field value to the backend. I can do something like this: (@request.body.businessPartner:isset = false || @request.body.businessPartner=businessPartner) && (@request.body.companyName:isset = false || @request.body.companyName=companyName)buuut this can get ugly real quickly. Or how would you suggest solving this? |
Beta Was this translation helpful? Give feedback.
-
|
@michael-schmid-wlw |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Just for info in case someone stumble here: |
Beta Was this translation helpful? Give feedback.
-
|
I'm writing a E-Commerce Rental shop web app for my business and have noticed that I'm often leaving a lot of the constraints to the client. Meaning, if a invoice is set to paid, I don't want to allow any API call to be able to change something. Right now this needs to be caught by the client, which works for my app now, but won't transfer my business logic to lets say a small serverless function I might run against the DB to onboard now suppliers in a different web app. Now I can do this via the API Rule and that works. But lets say I want to make sure no Name of a Product starts with a Space or any non letter - well I'm not sure I could do that via the API rule or if yes, then only via very long and winded if statements. It would be great to be able to declare constraints per column or maybe even functions that will run after a new item is added or one is changed. (I know this can be done via functions and listeners, but I would like my client to receive an error, if the write failed.) I wanted to offer a real world example, hope this helps clarify a use case. |
Beta Was this translation helpful? Give feedback.
-
|
isset can help stop the client from modifying certain fields but for more expressive constraints consider the jvsm hooks |
Beta Was this translation helpful? Give feedback.
-
|
I can suggest if we can create a separate "view" in pocketbase with only selecting those columns which we need to show and call them instead of calling actual collection. we can create multiple "views" as per our different requirements. I hope this can help somebody. |
Beta Was this translation helpful? Give feedback.
There are no dedicated field/column level access/visibility rules. You'll have to implement it on your own depending on your use case.
At the moment the easiest way to hide/restrict access to fields is to move them to a new collection with their own API rules.
This eventually will be simplified in the future, since there are plans to add a "view" collection type per #311 (comment).