Anyone Else's Edit Version Differ after Updating Confluence page via REST API?

Question

Length of Issue:

I'm not sure when it started, but it's been at least months if not over a year, and we've been through a number of version updates with no change to the behavior.  Currently using Confluence 6.6.0 (server).

Description:

When I update a Confluence page via the REST API, the normal page view looks fine.  It's updated.  When you go into Edit view, however, it shows an older version.  If a user does not notice/know it's an older version, and they edit it, then that older version with the new edits is what stays as the new version in normal page view.  Then we have to revert to the correct previous version, which works, then redo the edits.

Clues:

I can't be sure, but I think it goes back to a particular version (only in edit view).  I know this because I did a bulk update to a lot of pages and removed something, and that's what we look for to know if it's an older version or not.  At least in one space.

I started doing bulk updates in another space and notice the same behavior.  Only in that space, there's no way to know the version, and there are too many users to tell to look for something anyhow.

Like I said, it's been going on a long time, and there have been re-indexes galore, so I don't think that's the issue.

User Fix (Temporary):

The thing I've found that is a quick fix for a user is to open the page in edit view, make any change anywhere, like press the space bar.  Then click Close.  When it asks, select Discard all changes without saving.  That makes the edit and normal view of the page the same version.

Question:

Is anyone else having this issue?

Pain:

It's weird and annoying.  Now it's either update with the API and periodically check versions aren't messed up, then go back and manually compare and fix the messed up ones.  Or stop making bulk updates with the API, which means manually updating 10s or 100s of pages.  Either way, manual work.  Not fun.

WW · Answer

This issues seems to have been fixed a while ago, since I haven't seen it happen in a long time.  Granted, it's been a while since I've updated a Confluence page with the REST API.  Hopefully it's been fixed for everyone using a recent version.

RowanC · Answer

Hi @WW ,

I've just seen the same issue occur on Confluence Server 7.4, we updated a page with the API, then, when the page is edited manually, we see the old version.

We can workaround the issue by pressing "revert to published version" (under the three dots at the bottom of the edit page), but this is painful to do over several hundred pages, before letting users edit them.

Did you resolve your issue?

Thanks!

WW · Answer

I noticed that we have Confluence server 6.13 in another environment, and I played with the new feature in the ... menu.  I'm not sure that this "fix" gets to the heart of the issue.

From what you've said, the problem is that an old, shared "draft" is stuck out there from who knows how long ago, authored by who knows, that can cause significant confusion and extra work.

The root cause of *why* the old, shared drafts exist should be discovered.  If I update hundreds of pages via the API, and hundreds of pages have old versions in the Edit view, then the old, shared draft is not coming from true user collaboration conflicts.

I have to periodically go into my Drafts under my Profile, because there are always drafts where I didn't change anything or I created a page but didn't title it or put any content because I changed my mind about creating the page.  Those types of "edits" should not be saved automatically. Only when someone actually changes something should a draft be saved.  That should prevent at least some of what's going on from happening.

The new ... button also basically does what my workaround does, so the problems remain.  Users will have to know what the ... button means and to look for an older version every time they edit, which, honestly, they're not going to do.   Also, if you go into Edit view, and there are no changes, there should be nothing shown when the "View Changes" ... menu item is selected.  Instead, it shows you the page in storage view with nothing highlighted.  That means if a user even went that far, s/he would have to dig to find a small change in a big page.

I don't think a fix involving the user is the right path to take.  Even if it were a real case of simultaneous (people) editing, we wouldn't want one person's work to completely overwrite the other's.  From what I've seen, Confluence already handles this.  It will tell you who else is working on the page and what they're doing by putting a line and their avatar next to what they changed.  That helps users to not overwrite other people's work.  If that occurs when multiple users are editing a page, why would the ... menu be needed?  It wouldn't, because that's not why/when the real issue occurs.

The issue of there being old, shared "drafts" hanging around that were created, somehow, is the real issue.  In my opinion, there is still more work to do to actually fix this problem.