Ability to hide documents or content inside documents via user/group permissions or custom if-else/switch statements

I am writing documentation around using our Fibery workspace for members of our team.

We have multiple user groups, each with its own level of access and functionalities. Users can belong to multiple groups simultaneously, and Fibery treats the groups as additive whitelists. This is good architecture.

Our wiki sits under its own Space, subdivided into folders. Notably, Fibery documentation is split into ‘Quick Start’, ‘User Guides’, and ‘Help’. I’ve been diligent to keep all relevant information here, so users don’t have to search through the whole app for “how to do X thing”.

However, I’ve run into issues around the scope of visibility regarding documents. If a user has access to the Space (which they all do for the wiki) then they inherit read access for all documents contained within. A document could be irrelevant to most users, or contain sections which don’t apply to how they use the app. In these cases, I want to hide that information.

I’ve identified three possible methods for this that will allow this folder structure to stay the same: folder-level access, document-level access, and section-level access. There may be more options I haven’t explored, but I think these are the most intuitive.

Folder Permissions — Lock down or hide folders via logic. Yes, I know I could make all “folders” their own Space and lock those down, but that changes the appearance of the sidebar structure since Spaces have that distinct coloured squircle look. This suggested solution also avoids subdividing spaces into “Foobar Manager Space”, “Foobar Employee Space”, etc., since, in my professional opinion, Spaces should only be used when there is mutable data.

Document Permissions — Set on the document itself, applying to that and all nested documents to limit visibility.

Section Visibility — Having the option to wrap sections of documents in a code block, which can apply rules server-side that avoid fetching and rendering parts of the markdown. Could be as simple as highlighting a section and hitting an option on the toolbar that appears to “apply a visibility rule”, which would then allow the document writer to craft custom show/hide logic.

To expand on this last point, I envisage something like this (ignore the HTML syntax, it’s just what I’m used to):

// document.md
Document Heading
<display_rule=“User.Groups has any [‘Employee’, ‘Manager’]”>
Section 1 Title
</display_rule>
<display_rule=“User.Groups has none [‘Employee’]”>
Section 2 Title
</display_rule>

Naturally, Administrators would be exempt from the rules.

I would appreciate other users’ thoughts on the usefulness of this.

Have you considered using a “Folder” and “Document” database?

Then you could use a smart folder in the sidebar, and control access using entity level access control.

Interesting idea. Some immediate thoughts:

  • It’d probably need an orderby field to retain the same layout of the items within a Smart Folder.
  • Allowing create access to the database for all users with sufficient permissions does get around the issue of space editing. I like that in theory.
  • I assume all existing references will break once the documents are migrated, of which there are many.
  • Are you suggesting to use a rich text field as the document itself? That’s a little awkward imo since it doesn’t quite format the same.
  • How does this work with nested documents? A documents field and smart folder mirroring? How to prevent a child being its own parent/grandparent and infinite regress?

Default is the “Rank” order (set by drag and drop when there is no other sort set), so I think this is the same as default folders and documents. You can just drag and drop to set sort.

Good question. I know @cadsharp did a migration from native documents to database documents before. I think if you ask AI to copy the content, it will be able to do it for with the references intact, I’m not 100% sure though. You are referring to references between documents, right? Not to other entities outside the documents? (As the latter would be easier).

Correct. Under the hood rich text and documents are the same technology. What do you mean by “format the same”?

If you add a self-relation, you can not select the own entity within that relation. Fibery just won’t let you pick it. I think this guide explains it best: Fibery