Hello,
Is there any possibility of adding the ability for Guest users to fill out forms internally but leave everything else read-only, or adding a new permission level that allows ready-only access to everything, but still allow inputting forms without needing to generate a publicly shareable link?
I have a specific use case where I want to give access to only view everything, but still be able to capture the Created by User when they fill out a form.
Thanks!
What is your thinking for not wanting to use sharing links?
I canāt use the Created By field to run an automation using user derived fields.
Iād just make them Collaborators, but I donāt want them to be able to edit anything.
Also, it just feels off to have a form open but the user being able to do nothing with it.
Any other kind of view? Yes, I get why itās locked in Read-Only view.
I see.
Makes sense. We should look into it to see if thereās a simple fix.
Thanks Chris! I wasnāt trying to come off harsh on the last comment, it would just be such an amazing feature to be able to link to a form in the rich text and when they click on it, it pops the form up to the right ready to be filled. Specific to Guest Users or some other new level of course. Slick!
No worries. I agree that it would be neat.
To me it kinda contradicts the read-onlyness of Guests. If users really need to add data then they are no longer Guests to meā¦
Just to follow up on this, with a bit more detail:
Fibery uses permission logic to determine what a given user in the workspace is allowed to do with a form view:
admin/creator - can configure the form, preview and submit
editor/contributor - can preview and submit
guest/view-only - can preview
Of course, if the form is publicly shared, anyone (user or not) can submit via the āexternalā url, but the submission will be āanonymousā in this case.
As @mdubakov points out, if guests were allowed to submit āinternallyā (= recording them as creator) this would imply that they are performing an action that is only available with a higher permission level, at which point, they are no longer a guest(!)
As you are discovering, this means that guests can only submit anonymously, and there is a bit of friction for them to do this (they have to click a couple of times to get taken to the external url).
Sorry.
I see all points. How would you compare this to guests being able to comment on entities?
Well, if an entity is shared publicly, then external users canāt comment on them.
Signed-in Guests can add comments (both in rich-text and via the Comments field).
Blockquote
I think this is where Iām not seeing a clear distinction between a signed in guest that can put in comments internally versus a signed in guest that can fill out a form internally. I see an internal form as a more structured feedback field.
And to be clear, I am in no way trying to avoid paying for more seats on this, as I mentioned Iād just make them collaborators if they couldnāt edit, there just isnāt a permission level that fits the use case.
Thank you
Well, the limitation relates largely to the current permissions model, and we want to avoid coding an exception for form view.
Is it possible that the āContributorā permission level would be appropriate for these users? This is someone who can create entities, but cannot edit entities that he/she has not created or is not assigned to. These users are able to submit using the internal form.
Yes, that makes sense from the larger permission structure.
Contributor isnāt ideal (sorry I called it collaborator earlier) but it would be the best solution as things are now. I just donāt have a good way of maintaining the integrity of the lessons if people have the ability to create new ones (most likely by accident).
Iāll do some testing as a Contributor and see what it feels like.
Thanks again.
Maybe you could create a space with just the required form view (and underlying database) and give contributor access to the users who only need to submit.
Then you can limit their access (to read only or no access) for other spaces/databases so that they canāt add items in table views, board views etc.
Hmmm, that might work. Let me do some testing!
Well, itās almost a win. It works as I was hoping by splitting into two spaces with different permission assignments.
Unfortunately, I realized my views filtered by āAssigned to Meā only works to restrict access if they donāt duplicate to their My Space. I know this is expected behavior and am looking even more forward to entity level permissions and how you implement that.
Thanks again Chris for the help!
This āmy space duplicationā has been a limitation for several of my ideas as well. I want to onboard contractors and give them the ability to engage with certain views, but I canāt let them open up that database and create whatever view they want unfiltered.
Until entity level permissions is released, it would be nice if there was an option in a spaceās share settings that turned off the ability to duplicate or customize views from that space.
100%. If that could be implemented rather easily, it would be extremely helpful with limiting access to data only that user is assigned to. I essentially have 3 levels, with the top level having the assignment and that rolled down as a lookup field on the bottom two levels. Using the āAssigned to Meā filter works very well as a pseudo entity level permission, but only for permission levels that donāt allow editing of global filters, and of courseā¦my space duplication.
I understand the issue, and the real solution is per entity permissions (coming soon 
).
With the current permissions model, even if there were restrictions on duplicating a view to My space, it wouldnāt solve the fundamental problem that access is granted at the space level. Users will always be able to view entities in databases they have permissions for, not least by just using the search function.
To be honest, the way I tend to describe views is as a way to surface information to users to help them focus on what matters to them.
They canāt be used as constraints to limit what they can see/do.