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).
2 Likes
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)?
2 Likes
@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? 
2 years anniversary from the original request 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?
Let me provide you with another example. We use the Vacation tracking space (standard one). It contains several databases and folders with documents like policies. We want to keep policies read-only to avoid changes by mistake (human factor). I understand your idea to keep documents in one read-only space, but we want to split our spaces by purpose. Otherwise, it will be a mess.
Got it. Makes sense.
It’s likely to be implemented when the new permissions model rolls out (maybe not in the very first version but highly likely to be in scope in the short term)
1 Like