Our Confluence space has restricted access. There is a dedicated team (Admin team) who can make changes to Confluence content but rest of the 200+ users only have read access to the pages and cannot make edits. But the Admin team is dependent on the users for providing new or updated content for the pages which the the Admin team would review and then make the necessary changes.
Current Process -
Since users do not have edit access, they currently export the page in word, redline all the changes/add new content that they want and mail the redlined word document to the Admin team for review and implementation.
Problem Statement -
Exporting a Confluence page to Word breaks most of the various macros thus leading to poor structure and missing content in the exported word file. This becomes a problem when the content that the user wants to change does not get exported in the Word file itself (eg. images, tabs, etc.). Thus they have to copy paste the same thing from Confluence into the exported file and then make changes. Which is double the effort and an unwanted complication.
Alternative Solutions Tried -
Is there any way to export a Confluence page that keeps all the content from the original page and makes it available for redlining? I do not expect macro functionalities to work in an exported document but the content should all be in there. If there is any other approach that I haven't tried, please do let me know.
Thanks a ton!
I believe that your discussion with @Thomas Bowskill sparked your separate post 'How to hide all other states except the Final state from non-collaborators/reviewers in Comala?
Hopefully my answer there is sufficient.
Senior Product Manager
Hi @davin ,
I would also suggest you another solution. Talk Inline Comments has the Talk Restrictions feature. It helps you to set up default visibility restrictions for talk inline comments over a space. Thus, users can leave inline comments, but they will be only visible for the users or groups defined in Talk Restrictions over a space.
Talk Inline Comments work when you enable Page or Comments Restrictions over a space level (as well as native inline comments), but native inline comments don't have the restrictions feature and will be visible to everyone who visits a page.
I suppose it depends on whether your Confluence access is a license issue or not (i.e. you are read only because of the company not wanting a high licenses bill, rather than it just being policy to lock down who the editors are).
If you have the licenses... could they go and create you a copy of the page in a space you can edit... but that won't really do the redline (unless you inline copy that version).
@Thomas Bowskill We have Comala Document Management if this is the one that you are suggesting. But my understanding of its functionality was it is only for managing approvers and reviewers. Does it have the functionality of someone who doesn't have edit access to a page, to suggest changes/add new content to a page and create a draft with all these proposed changes that the Admin team can review and accordingly implement in the actual page?
Also, we have full Confluence license across the entire enterprise. Users did have edit access to pages which led to a lot of rampant changes and zero governance over the content. Which is why this Admin team was put in place to manage, review and implement changes. In short, its a policy we have chosen, not a license limitation.
I am part of the Admin team which oversees this. I just want to provide an easier way to collaborate on updates and changes for our users while maintaining governance over the content.
Thanks for the context @davin
I would assume with Comala you delegate the edit access to more granular levels (can edit, can't publish), but it has always been one that I've kept an eye on rather than opted for, as my Confluence instance has a manageable number of people actively editing. Hopefully someone with actual Comala experience can jump in on that part.
Without knowing of other options, I would consider copying the pages to a space where people can edit, letting them make the edits on that page and then reviewing those changes via the Page History screen. Then you can copy the page back and supplant the older one (which might be a pain if you have page IDs...). Or you let people request edit access and provide this on a short-term basis only -- get them to go in, make the change, have it reviewed and choose whether to keep or revert. You're still delegating trust that they don't go wild with their changes, but you're also time-boxing it and remain aware of what people are editing, and can give feedback when their edits are wrong.
Not sure if I've helped much, but hope you found something there that was useful! :)
Thanks a lot Thomas for your time.
We do have a lot of cross linking and child pages in our space so replacing a page with an edited version of that page from another space wouldn't make much sense as the follow-up effort would be unbearable for the Admin team.
You did spark a small idea that I might have to dig deeper on. What if we gave edit access to all and implemented Comala to review the changes by the admin team before implementing them live. That might be a way out. Let me look into it and also understand better on how Comala actually works as I too have never used it.
Till then, hoping anyone with Comala experience can share their knowledge.