Comment visibility follows base Viewer access — anyone who can read the entity sees every comment on it, regardless of their actual access level (Viewer, Commenter, Editor, Owner, Observer, Guest).
No way to keep part of a thread visible only to Owner/Editor-level holders while hiding it from Viewer- or Commenter-level parties on the same entity.
On any entity shared across mixed access levels, this means comments are all-or-nothing: on for everyone, or off entirely.
The ask:
An “Owner/Editor only” flag on an individual comment or reply.
Visible to: Owner, Editor.
Hidden from: Viewer, Commenter, Observer, Guest.
Scoped to the comments mechanism itself — shouldn’t need changes to the general field/access permission model.
Why it matters:
Makes Comments usable as a real collaboration channel on entities shared across mixed access levels.
Removes the current workaround of a second database, or a tool outside Fibery, whenever higher-tier-only discussion needs to happen on the same record.
This should be set per comment in your mind? Not for all comments within that entity?
My thinking would be for Fibery to treat comments like a to-many relation, then you can have many comment fields, each field can have different controlled permissions.
But if you really need it on a per comment or per thread basis, I think that makes things more complex… Both for how it works, and also the way the end user will interact with it… It means the person writing the comment needs to see a list of access templates and decide which access template should see this - per comment they make. I think that’s quite a bit ask, even if technically possible.
Would different comment fields with different access control fix your use case? How do you currently handle this issue?
Unfortunately, per comment, the difficult one. Many comment fields with templates will not solve the problem due to the absence of field permissions where individual fields can be hidden based on permissions or templates.
The way this is currently handled is to not use the comments field with accompanying inbox functionality but to duplicate the comments fields in two separate databases with records linked to the original record where the comments field would have been used. This is the only workaround for the lack of field level permissions, splitting one database into two or more with duplicated records grouping the fields of the duplicated (extended) record across databases to provide field permissions not at field level but at database level.
Managers can see and comments for everyone and their managers, and everyone else can only see comments for everyone, not the comments within the “For Managers” relation.
Based on what you are saying as your current workaround, it sounds like a similar scenario. Trying to understand the underlying problem here to explore what possible solution there may be.
