I brought this up via intercom, and was told that this is a missing feature and not a bug. Sharing here with more details and to see if others have encountered this and to discuss if it’s a bug or missing feature.
Setup:
Invoice DB with a many to many relation to the Tag DB
Give a user Submitter access to the Invoice DB, and view access to the Tag DB.
Remove the default “Created by: Editor” permission.
Result
A user can not submit an invoice because they do not have edit access to the Tag DB. It throws an error: “Sorry, you can’t edit ‘Tags’ fields on ‘Invoice’ database”
Why I think it’s a bug
- It’s only a problem when the submitter is setting a to-many relation where they don’t have access to either side. Not a problem for to-one relation fields. Not a problem when they have/will have edit access to either side.
- I gave the users Submitter access. It is expected for them to be able to submit. (Note that this doesn’t prevent users from deleting, linking/unlinking invoices from tags. But it does prevent creation + editing simple fields)
Simple Solution
The only way around this is to give edit access to the Tag Database or allow the invoice creator to edit their own invoice. Since the invoice is more sensitive, and we don’t want them to edit after creation, I will go the route of allowing editing of the Tag database. This is far from ideal though… As this also allows users to unlink invoices from tags, even though they don’t have access to the invoices themselves.
Workarounds
Of course, there’s a Fibery workaround.
- You leave on the default “Created by: Editor” and add an automation which revokes this privilege on create. Its a bit finicky, since if you press “Create and Open” in the dialog, you will actually still be able to edit until you refresh. Not the end of the world, but interesting that it does that.
- Give Editor access to the Tags, but add validation rules on create and on update that then restrict create and edit access to only a specific role/people.
I get that a future feature can help control this. I think the main issue here is that when giving Submitter access, the user should be able to submit to that database, irrelevant of the access they have to the related databases.
Curious what the community thinks.