nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Comala Document Management: confidentiality is broken

Franz_pj31qr

Hello,

Confidentiality is compromised by comparing the page history or by viewing (subscribing to) all content in space.

If you try to access a page for which no published version is yet available, and you do not have permission to view drafts, you can navigate to the page history and compare versions to view the page’s content.

If you subscribe to the entire site, you will receive the confidential (unpublished) page content via email.

Is there a solution to enforce confidentiality?

Thank you in advance.

Accepted answers

oliver cuesta

Hello @Franz,

Thank you for raising this. I understand your concern, particularly when unpublished content is expected to remain confidential until it reaches the final workflow state.

Assuming you are using same-space publishing, the behavior you are seeing is related to a known limitation of how this publishing model works in Comala Document Management.

Same-space publishing allows the draft and published versions of a page to coexist within the same Confluence page. By default, users with view-only permissions are directed to the latest approved version, while editors can access the current draft. However, because both versions remain part of the same underlying Confluence content, same-space publishing should not be considered a security mechanism for completely hiding draft content.

This limitation is documented in our documentation:

https://support.appfire.com/space/CDML/649794062/Same-space+publishing#Overview

In particular, the documentation explains that the latest content may still be accessible through Confluence functionality such as the page history or search index, even when a view-only user would normally be shown the approved version when opening the page directly.

If your requirement is that draft or unpublished content must not be accessible at all to certain users, we recommend using different-space publishing instead. This separates draft and published content into different Confluence spaces, allowing you to use Confluence's native permissions to completely restrict access to the draft space.

I appreciate that this may require a different setup from the one you currently have, but it is the recommended approach when confidentiality of unpublished content is a formal requirement.

If you would like, please open a support request with us and share some details about your current workflow and publishing configuration. We would be happy to review the use case with you and help determine the most appropriate setup.

Kind regards,

Oliver
Appfire Support

All comments

Fabian Lim

Hi @Franz ,

You may want to create a ticket with Appfire who is the App Vendor directly. Link: https://support.appfire.com/page/support

Regards,

Fabian

Tiago Paladino

Hi @Franz ,

I think you've spotted a real limitation, and it's not really a Comala bug, it's a consequence of how the app works on top of Confluence. Comala adds a permission layer on the page view, but the underlying versions still live in Confluence's normal storage. So anything that reads directly from that storage (page history, watch notifications, exports, search API...) sees the raw content and bypasses the workflow rules.

There's no single switch that closes all these holes at once, but you can layer a few things to get much closer:

Restrict the pages themselves. Combine Comala with Confluence's native page restrictions. Set the draft/unpublished pages so only the authors and reviewers have view access at the Confluence level. This is the strongest fix because it removes the content from history, notifications and search for everyone else, not just the Comala UI. Comala has automation actions that can apply and remove restrictions automatically as the page moves through the workflow states, so you don't have to do it manually every time.

Turn off "include page content" in notifications for that space, or better, disable watching at the space level. In Space settings > Mail, you can strip the content out so watchers only see a link, which then respects permissions when clicked.

Consider splitting spaces. For anything truly confidential, a dedicated space with tight permissions is safer than trying to hide drafts inside a mixed space. Publish the finalized version into the shared space when it's ready.

PS: don't rely on Comala alone for confidentiality. Use it for the workflow, and use Confluence page restrictions for the actual security.

oliver cuesta

Hello @Franz,

Thank you for raising this. I understand your concern, particularly when unpublished content is expected to remain confidential until it reaches the final workflow state.

Assuming you are using same-space publishing, the behavior you are seeing is related to a known limitation of how this publishing model works in Comala Document Management.

This limitation is documented in our documentation:

https://support.appfire.com/space/CDML/649794062/Same-space+publishing#Overview

I appreciate that this may require a different setup from the one you currently have, but it is the recommended approach when confidentiality of unpublished content is a formal requirement.

Kind regards,

Oliver
Appfire Support

Kris Klima _K15t_

Hi @Franz

I'm just going to reiterate @oliver cuesta's idea to use the different-space publishing approach.

I used Comala apps precisely to take advantage separating Authoring environment (where your workflow happens) from Reading environment. Authoring space has limited access for those few who can edit. Reading space is read only for the rest of the company.

This arrangement greatly simplified permissions setup and, at least in my use case, I found no drawbacks. It was also beneficial for reviewing and back-tracking changes.

Authoring space has all the edits, tracking the collaboration history.

Reading space has only the approved, final versions of the pages, making any deep dive (or compliance requirements), much easier.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

data-center

comala-workflows

confluence-data-center