Read-only documents

JIRA has good sharing set up.

Documents need a lot of work and I’m dissapointed to see the team is not focused on solving this. I end up getting back to Clickup and Coda for this and I hate it.

Some things that are required:

  • option to share the document link to others read only
  • Setting different colors for text or backgroud of the text(highlight)
  • checkboxes inside a document can’t have sub-items/sub-checkboxes
  • cannot link to different places of the same document for navigation
  • cannot drag-drop content blocks

These are the major one Fibery lacks for a good enough documentation tool to replace Clickup/Coda


I have to say I’m concerned too re: pace of development. My team’s pain on a daily basis as we struggle with Fibery’s shortcomings, such as this missing feature, is real. The one ray of hope had been the team’s periodic declarations that they want to build what we are missing. But Twitter is almost devoid of real organic feature updates these days. And I can’t see what Fibery 2.0 is going to add that we don’t have, so with that big day coming, I assume nothing new is around the corner anytime soon because of the focus on 2.0 and whatever it includes. The team hasn’t really said much of substance here in Discourse lately, either. By that I mean specifics on when, not if, a discussed feature badly needed, like this one, is coming.

Hi @B_Sp and @Jean

I agree that we don’t release many features last months, but there are reasons for that. Mainly infrastructure changes and performance improvements. In the next few weeks you can expect:

  1. Mentions in inline comments
  2. Entity History
  3. Hierarchical Lists

We also started Automation initiative, it is huge.

As for documents improvements, we do have the nearest future plans to improve them, but we have to think deeply about the current rich edit implementation, since we have many interesting ideas on how to make documents construction mich better.



Thanks in advance!!!

I’d love to see block-based editing (drag+drop), and I have some thoughts about how the UX should be handled if indeed that gets added.

But mostly I just wanted to add support for the much simpler and hopefully faster to implement suggestion of allowing nested checkboxes. I find this to be a tremendously useful feature in the other tools that support it. Also allowing some kind of bulk operations on check boxes would be nice (though low priority), e.g. “Check/uncheck all” and/or “Check parent and children” (check all boxes nested underneath another).


Agree drag and drop of blocks as well as nested checkboxes would both be great. I’d love to see checkboxes take on some more structure, like being able to be simply assigned and given a due date - both and Clickup make great use of this and it’s very useful for development. In fact, there are a ton of Jira apps built just for this purpose to help with Acceptance Criteria, etc. so you don’t need full-on tasks to handle that need.


@mdubakov @Polina_Zenevich hi guys! Any updates on this? It’s super annoying we can’t provide a read-only for our users. Documents can be changed by mistake because they are always in edit mode. Right now we don’t have even a way to see changes history and restore a back-up.

If it’s possible to just provide a button “Make read-only for non-admin” or something like that, it will be super helpful. We don’t want to move back to Confluence. But the truth is Confluence is so much better than Fibery for documents management :frowning:

@Eugene_Vabishchevich Is it related to Documents only? Why you don’t have similar problems with other entities like Tasks?

@mdubakov because we have documents with a lot of content inside. And technically it’s just one big field to edit. All other entities have several fields and it’s not that easy to change it by mistake.

Permissions is similar request for entities as well. But Polina said permissions will not cover documents. That is the reason why I follow up this thread.

1 Like

It is hard to buy this argument since there is not so much difference. Let’s say we use Features and Ideas a lot and in these entities, descriptions are huge quite often, so they are very similar to Documents. Again I want to have specific cases to think about the solution.

“Make read-only for non-admin” is anti-collaborative :slight_smile: What exactly you want to restrict and from whom?

In general potential solutions are these:

  1. Document changes history with Undo (this is planned)
  2. Read-only access to an app for some role (it will be a read-only access to ALL Types and Docs inside the app) (this is also planned).

For example: we have a big document about vacation policy. We edit it sometimes but in general it should be just for read-only access. I know it sounds strange “users can change it by mistake” but as a product management tools developers you know better than me users behaviors can be super strange often :slight_smile: And now in Fibery there is no feature to see changes or block edit in document/entity.

I would they both of these can help. The second one is better :slight_smile:

My question: when you are saying “planned” what does it mean? Could you provide some ETA for these points?

1 Like

We are working on history and starting permissions re-work next week. It’s hard to provide ETA, but I do hope it will be from 2 to 4 months (not a promise).


Another approach, especially for a knowledge base or handbook is to let everyone contribute by “proposing changes” that are reviewed and accepted/rejected by the maintainer of the page.
Gitlab Handbook (Handbook | GitLab) does that. It is really good to have a culture of participation, decentralizing documentation, but still, keep it under control. At GitLab it is implemented using git and merge requests (similar to GitHub pull requests), so a bit technical for non-tech people.

Fibery could have a similar feature, with an editing workflow extension, reusing the assignee field:

  • edits are pending, not visible to others, or could be via Comments maybe?
  • assignees receive a notification
  • they have a button to accept/reject the edits
    The input of changes could be done with the inline comment feature, adding another action than “resolve” for the editor assignee, but not sure it is the best idea to mix the features.
    Another interesting property of using git for the Gitlab handbook is that someone can create a bigger change that affects multiple pages, that will be reviewed and accepted/change as atomic. When you start to have a big knowledge base, some “doc refactoring” will happen (reorganizing the pages, table of content, renaming, etc.)
    Also, Rich Edit field changes are not tracked, so the “modified date” field is not right, nor the activity stream, so not possible to see what has changed. This should be fixed for the feature to be usable.

@mdubakov I’m the only one who needed an editing workflow (a simple static one with one level of approbation is good enough)?


@JMaynier I guess permission feature for the read-only is in development.

Seems like approval process you suggested should be created as a separate one.

1 Like

Indeed. If I were on Fibery team I’d fork the above post to a new feature request topic…

Hi @Polina_Zenevich @Chr1sG @mdubakov ! Any updates about the permission feature? :slight_smile: 2 years anniversary from the original request :slight_smile: Sometimes we need to provide read-only documents like company policy, project requirements, etc.

1 Like

Have you thought of having a space dedicated to storing docs, with no access for anyone except admin, and then sharing docs with links (external url)?

Good idea, but we do not want to hide these docs. Just disable editing.

Ok, maybe I’m missing the point, but couldn’t you create a space where only people who need to edit the docs have permissions, and everyone else is read-only?
(forget external urls)

Or is it critical that the docs live in spaces where ‘normal’ users have edit privileges?