Hey! I’m in the process of remaking Hubspot inside of Fibery in order to push Fibery to it’s limits and see what’s possible. That being said, I found my first limit!
Pre-population of internal forms.
When adding an entity from within another entity’s relationship, it nicely pre-populated the relevant form field with the entity I am adding from. However, I would love to be able to pre-populate from other relationships this entity may have. Such as the company the contact i linked to, or (a bit more complex) the currently open deals that are related to the contact.
Since this doesn’t work, I thought filtering the related views could work, but since the entity is not actually created yet within forms, the filtered view in relationships is not functional. I’m not sure how difficult these would be to implement, but they would save tons of time.
This is somewhat similar to a discussion here: Dependent Dropdown Field Type, but then functional within internal forms. (External forms would be nice too, but I believe they don’t see relationships as internal forms do.)
We have a feature in our backlog which covers the case of dynamic relation filters in forms (i.e. limit the options the form-filler can choose from, based on the values chosen in other fields of the form) but we have no eta, and form view is not in focus at the moment, sorry.
Okay, makes sense! Looking forward to it once it’s out. I think the internal forms have huge potential in creating solutions for people who are not as tech savy. Stops people from potentially inputting garbage (!)
(Thanks again for the replies on the videos!! Didn’t expect anyone to actually sit through it all haha.)
That sounds great =)
Do you also plan to enable access entities in forms which the user has an entity-based access to via access-templates?
Currently you can either see everything if you have access to the space, or not.
Do you mean limiting the entities shown in the dropdown for a relation field on a form?
If so, I don’t think we have a feature request for that yet, but it kinda makes sense.
Not sure what it would mean for external (anonymous users) filling in the form…
Yes, enabling or limiting, depending on
a) User has no access to space but to entity → should enable to see the entity
b) User has access to Space but revoked entity access → should limit the entity
In any case such that the entity-level access is correctly depicted in the form-view, as currently the form view only takes space-level-access into account.
There is no such thing as ‘revoked entity access’. Permissions are positively cumulative, so if you have space (and therefore db) access, then you can’t exclude specific entities.
This is a capability that you can grant to someone, which will allow them to remove entity-based access for other people. But if those other people have access via space/db based permissions, it does not remove that from them.
Sorry for the misunderstanding.
As it stands, permissions are only ever ‘additive’.
Looking forward to what more will follow, I’m sure you guys will nail it.
Please don’t forget it was the most requested feature, it is really hard to implement things otherwise. Even with all the power and flexibility Fibery has, I couldn’t even consider to expand Fibery into more processes just due to limited access control. Now I can cover some more use cases but it’s still clearly limited and cumbersome workarounds are needed.
