for the visibilty of the non-editable field, and the inverse condition for the editable field.
Use a similar statement to navigate to 2 different detail screens, one of which is editable and one of which is not.
My concern:
Is it possible for users with malicious intentions to edit the invisible editable fields when they should only have access to the non-editable fields? I can imagine that a malicious user with sufficient expertise could send a response to the app to edit the invisible field without the app being able to object, since the invisibility is not a security feature.
Is it possible to access the editable screen when you are not supposed to be able to do so, when someone who does have access to this editable screen (through a different account) provides you with the URL for this screen?
If both of these options cannot be considered secure, is there an alternative, secure implementation?
I'll let someone from HC confirm, but I'm pretty sure that visibility isn't really 'secure'. If you want to securely control editing like you describe, I think you need to make a duplicate app for each permissions group. Assigning users to apps is secure.
Hey @Beno-9aed welcome to the forum and thanks for your question. Your intuition is right in that visibility is not a security feature. Please refer to App Data & Security for details on securing your data.
Your case may be unique in that it's not an attribute of the row that you're trying to use to secure your data, but instead, you're trying to secure it based on user's privileges on it regardless of what is in the data. I can think of two ways of doing this.
The first way I could think of doing this is to have two lists in your detail screen, one with source =Filter(Database_Users,"Database_Users[User]=UPPER($[SYS_USER]) AND Database_Users[User Access]<>%", "Restricted"). You could then put all the shared editable data cells in this List with sources like =$[Input Row][Column1], =$[Input Row][Column2] etc. The second list could have filter as =Filter(Database_Users,"Database_Users[User]=UPPER($[SYS_USER]) AND Database_Users[User Access]=%", "Restricted"). You could then put all the shared non-editable data cells in this list with similar sources as above. The above works under the assumption that there is only one row in Database_Users table per user, and the filters above would contain either one or zero rows.
An alternate approach I can think of is to build two different detail screens following the approach #4 in the article above. One of the detail screens can have editable data cells, and another could have a non-editable data cells. You could then constrain the Input Row's picklist filter source so it contains the entire table or not depending on whether the user has edit privilege. For instance, the picklist filter source for Input Row for the screen with editable data cells could be something like =Filter(My_Table, "NOT(ISERROR(FindRow(Database_Users,"Database_Users[User]=UPPER($[SYS_USER]) AND Database_Users[User Access]<>%", "Restricted")))"). Similarly the picklist filter source for Input Row in the screen with non-editable data cells could be set to something like =Filter(My_Table, "NOT(ISERROR(FindRow(Database_Users,"Database_Users[User]=UPPER($[SYS_USER]) AND Database_Users[User Access]=%", "Restricted")))"). You can then use conditional visibility to show a button to navigate the user to the correct detail screen from your list screen. The approach is secure even with conditional visibility because even if a user who has no write privileges does get to the screen with editable data cells, the picklist filter source would be an empty filter, and they cannot edit any details for an Input Row not actually contained in the filter.
Let us know if either of these approaches do not work for you. Happy Honeycoding!
To be able to implement other features (data validity checks) I have in the meanwhile switched to variable sources with a save and delete button. As a result I cannot implement your first suggestion since lists only allow shared sources.
The second suggestion works perfectly!
If anyone has the same problem, I should note that for reasons still unknown to me the code you suggested:
raised an error about the invalid use of Database_Users. This was solved by pasting the
=NOT(ISERROR(FindRow(Database_Users,"Database_Users[User]=UPPER($[SYS_USER]) AND Database_Users[User Access]<>%", "Restricted"))
in a seperate invisible 'DataCell' and refering to it in the filter using
=FILTER(My_table,"$[DataCell]")
, which results in the exact same code.
Now that I am using variable sources, another solution became also using the condition I used for the visibility of editable fields as the if statement of the automation for saving or deleting changes.
PS: Thank you for the more robust implementation of this condition using ISERROR().
