My case is really simple : as a service company, we have projects with tasks on which we record times, docs, comments and a lot of other things related to invoicing, planning, … Thanks to the flexibility of Fibery, it’s a joy.
For some projets, we would like to collaborate more easily with our customers so they can follow the state of each task and perhaps comment on some or add details. We don’t have particular requirement, just basic stuff.
So when I saw that new features for collaboration where available, I tried to make use of them.
I first tried the simple “public read only sharing” :
the customer don’t need to authenticate > perfect
it’s read only > ok
he can access all the “simple” fields > not good
he can’t view tasks (even if it seems possible because a counter is shown) > blocking
in this case the customer can see the tasks but only in a list view with only the label (no filter on status, no kanban with the relevant props) > not usable
but all the other related collections, that I don’t want to share are also available > blocking
So I tried the guest feature that seems designed for this usage. I even upgraded for a pro plan to be able to extend the access via “access templates” :
the customer needs to create an account > ok
he needs to understand a welcome screen with smart folders he don’t have access, a blank dashboard with advance features and find it’s way to the inbox, I guess > quite intimidating
and when he opens the project, he can see everything : the tasks but also all the “simple” fields even the confidential ones, all the entity views, the reports, the history, the sharing… > way too much, too complicated and unrestricted
… but he can’t create a new task > I don’t understant
At the moment, neither guests nor observers can create records, so your customers would need to be Members.
Fibery does not have the concept of field-level permissions - when an entity is shared, it is possible to control who can see linked entities, but all the primitive fields (numbers, dates, text, etc.) are accessible.
Unfortunately, it sounds like there is no solution that would be acceptable*
*it is possible to create the effect of field-level permissions by creating ‘shadow’ entities to store the fields that are sensitive (and not granting access to these shadow entities). It complicates the structure and UX/UI however
J’ai été confronté au même type de problèmes. J’ai voulu partager des entités avec des personnes qui n’ont pas de compte Fibery.
La première chose frustrante est le fait que quand la personne se connecte et qu’elle n’a pas accès à l’espace qui contient les entités auxquelles elle a accès, elle doit les chercher. Aucun menu n’apparaît sur la gauche. C’est assez perturbant car ça donne l’impression qu’il y a un problème alors que c’est le fonctionnement normal.
J’ai essayé plusieurs choses et le seul moyen est de créer un autre espace qui ne contient que des vues dédiées pour ces personnes sans licence. Ça ne règle pas le problème des champs confidentiels mais ça règle le problème de visibilité.
Pour le problème des champs confidentiels, Fibery vont mettre place la possibilité de cacher les vues des entités. Cela signifie que tu pourras créer une vue spécifique qui ne contient que les champs que tu veux voir apparaître pour cette catégorie de personnes.
Just to be clear, hiding of entity views is not the same as field level access control.
If a user has access to entities, they will be able to create a view (table, list etc.) of entities of that type in their personal space, and in this view they can enable visibility of any fields they like, including ones that are not otherwise shown on entity view.
TLDR hiding fields from entity view != hiding field values from users
It’s true that I didn’t thinked about the personal space. I didn’t tried but if he only wants his customers to comment, then the customers will only have Observer access. Observers can create views on their personal space ?
If it’s the case or if he really needs to give member access, then creating a separate DB with his confidential fields seem to be the “technical solution” but not the best solution that we should be able to apply.
It confirms my thoughts about the low support of Fibery for this kind of collaboration with customers or partners that require more fine grained permissions and easier/simpler UI.
Which is quite strange, since it is a use case described in the documentation and, I think, should be quite common among Fibery users.
In the mean, I think I will have to copy/paste to a Trello board or perhaps use make or something…
Don’t hesitate to tell me if you have better ideas.
But if you want to have internal fields and client fields, you can add a database called “Client Portal” and autolink all the relations and share it with them as a guest.
I’d be happy to help out with this, feel free to send me an email: ron@ronmakes.com
The biggest down side is the lack of “Create” functionality for guests, but even for that there are workarounds that aren’t that complex.
But way too complicated and hacky for a raisonnable project collaboration with clients or partners. If someone at Fibery is reading this, please look at the video and please tell me why we need so advanced usage and workaround to create a client portal… which will certainly break at the next version.
So sad you seems to consider the subject quite done when it is clearly not supported even at a basic level. What the purpose of the “pro” plan with customized access templates, etc… if the only mode of collaboration really supported is “all or nothing” ?
Excuse me but I was hopping I got something wrong and I discover that is not addressed and will certainly not be. I would be please to have your answer on this. I think it will help other users too that would like to create a project management feature.
As I wrote above, Fibery does not have (and there are no plans for) field level permissions.
Based on how you describe your need, there is no way to achieve what you want.
As far as I can tell, the closest you can get without any crazy workarounds is public sharing using custom access templates, so you can choose which related items (e.g. Tasks) a customer sees when looking at a Project.
However, they won’t be able to add/edit content.
You could provide (and publicly share) forms to allow customers to create new items, but it will be disjointed from the shared entity views.
