Changing the owner of a page version on api level

[Steve Gerstner [bridgingIT]]

Hi @all,

I have to remove old unsused users from the system based on compliance rules. A part of this is to transfer all the page versions owned by such a user to another user. 

Everything is under control besides the history page 

https://confluence.atlassian.com/doc/page-history-and-page-comparison-views-139379.html

What I know is, that I have to change the contributor set of the version history. What I not know, is how?!

Has anyone any idea how to do that, how to achieve this with tha java API?

Regards

Steve

[Steve Gerstner [bridgingIT] · Accepted solution]

I got it...

Since I'm using confluence to manage the LDAP in the background,

• I'm deleting the old user
• switching to the internal directory
• creating a new user with the same id
• renaming this user
• switching back to the ldap directory

[AnnWorley]

Awesome! Thanks for sharing the solution you came up with. Your use case is unusual but I can see how it may come up again. Please keep us updated if you run into anything unexpected.

[AnnWorley]

Hi Steve,

I am having trouble understanding your use case. Confluence pages don't have owners in the sense that files in an OS do. Anyone with the permission to edit them may make changes. The last person to make changes will have the byline for the latest change: "last modified by...".

Is it your goal to have the Changed by column in the page history comparison view credit the changes to a different user from the one that is now displayed but no longer active? It seems like that would show an inaccurate history of the page so I am not sure why it would be desirable.

I look forward to learning more about the changes you would like to make via API.

Thanks,

Ann

[Steve Gerstner [bridgingIT]]

It's the "changed by" column, but you can't edit this relation between user and content as far as I figured out at the moment.

My customer is giving away user ids from former employees to new employees. So we have to "free" theses user ids. The whole setup is unlikly complex, as they use a "custom" directory based on webservices rather then on ldap. So we have an ldap server as some kind of proxy, which is feeded by confluence as you can't redirect the password challenge from the internal directory to the ldap, but you can with a ldap connector. And it's at least as confusing as those lines are ;)