We are thinking about creating a knowledge base in Fibery. The problem right now is it’s possible to edit documents accidentally. It would be great to just make them as a read-only. Ultimately to provide edit rights to specific users.
I believe Entity-level permissions are on the roadmap.
2 Likes
Thanks. Good if it is.
Yes would love an update as to when!
Yeah for a large subset of my entries, I rarely want to edit them after the fact, but have fat-fingered a few in my time. Would love to “lock” these.
rich-markdown-editor has a nice feature: you can allow tick-boxes to be filled for otherwise read-only docs
1 Like
Hi!
To be honest, I am not sure that would be implemented in the nearest future. I’m not sure either whether it would be solved by Entity-Permissions as well. I understand the idea - it is more like “locking” documents/entities, protection from accidents - not a strategy policy.
We would continue collecting such requests and will see, whether that can be a case, that will be supported by one of the planned features from the backlog.
Thanks for the interesting case to think about!
@Polina_Zenevich sad to hear. Things like that stop us with migration to Fibery.
Curious to know, where it will be solved better. Would be glad to learn better practices! 
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
4 Likes
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.
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:
- Mentions in inline comments
- Entity History
- 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.
2 Likes
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).
3 Likes
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 Clubhouse.io 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.
Thanks!
@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 
@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 
What exactly you want to restrict and from whom?
In general potential solutions are these:
- Document changes history with Undo (this is planned)
- 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).
2 Likes
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 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
My question: when you are saying “planned” what does it mean? Could you provide some ETA for these points?
1 Like