Is it possible to transfer page ownership to a new person?

[Armando Moncayo]

Hello team, 

I would like to transfer the ownership of a page I created to a new person. I didn't find the option in the UI. Is it possible to do it?

[Bill Bailey · Accepted solution]

Well not sure what you mean by ownership of a page. The person listed as having created the page? What are you trying to achieve?

Those values don't really mean anything for the operation of Confluence, so no need to "transfer ownership". Any one with permissions can access and edit the page.

You could theoretically update that value through the API, but there is no real reason for doing it.

[Zack Howard]

"You could theoretically update that value through the API, but there is no real reason for doing it."
We have a use case that could benefit from this, but I have not seen the documentation on it, would you be able to point me in the right direction? I was searching the REST API documentation but couldn't find the page owner properties.

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the Atlassian Community!

Confluence doesn't have a concept of "page ownership" beyond "the owner of the page is all the administrators of this space".

If you're looking at Author, the person who wrote the page, then that's not right.  You can't change the Author, and you don't want to - it would destroy the information about who created the page.

[RPT Admin]

While I agree with you, this is a real weakness for organisations using Confluence as a knowledge base, because the lifespan of a page can be vastly longer than the involvement of the original author. This can lead to the situation where admins simply don't know who has responsibility for a page. 

I appreciate this is less a problem for pages which are genuine collaborations among multiple staff - and I appreciate too that the principle use case for Confluence is collaboration rather than content management. But the reality is that some of us who have been using it for a long time _are_ using it for content management. And this is a constant source of frustration. 

Just to be clear I agree your answer. But I've seen this question get asked multiple times in the years I've been using this forum. It's something I didn't realise when I signed up 8+ years ago, and if I had realised, I would probably have continued looking for a more suitable product. 

Thanks for the helpful reply - it's important that this limitation of Confluence is as visible as possible. 

[Bill Bailey]

Well when confronted with this issue 10+ years ago, I started adding metadata to pages (and then displaying that data with a user macro) to show who the page owner was from the stand point of content. I was creating most of the content structure, so was shown as the original author. This method also allowed me to re-assign page ownership as needed.

Then I could use this metadata for reporting, or for our publishing process built using Comalatech Workflows (plugin name has evolved since then).

[Stephan Voigt]

Hallo Bill,

that sounds interesting, I'd like to learn how you did this. I can have a header table with an owner, but this is still hard to report or to have an overview on all pages. any macro's that help for this?

[Franz Reichard _Communardo_]

Hello @Stephan Voigt,

thank you for your question.

As I can see you are interested in adding metadata to Confluence pages. To achieve this I would like to introduce to you our app “Metadata for Confluence”. With this app you can add metadata to each page. There you could set the responsibility for a page independently of the author or person who last edited the page.

If you have further questions or support requests about our apps you can also contact our support directly.

Kind regards,

Franz
Communardo Support

[William Wilson]

The repeated short sightedness in these forums frequently floors me.

Confluence doesn't have a concept of "page ownership" beyond "the owner of the page is all the administrators of this space". [...] You can't change the Author, and you don't want to - it would destroy the information about who created the page.

This is stated as though there could never be a need to change ownership. The number of reasons a person may want to change the ownership are not up to you. 

In our case, we recently migrated from server to cloud. We were using AD for auth in server, and we are using Azure AD and Access in the cloud. 

The system migrated all the data over with user information. But when the users migrated over, about 1/3 of our users got migrated from sAMAccountName with 'outside' email addresses to UPN. Now that they have to log in with their domain account (and domain email address), they are no longer seen as the authors (or owners) of their old data by confluence. 

How do I take ~100 users who all have several hundred pages that they own (tens of thousands of pages), and make them the author of their pages again? Many of these pages are private pages accumulated over years of work, and not collaborated "team" space pages.

"You can't do that, because we never accounted for deviance from our box" is a HORRIBLE answer. 

And "There's a marketplace app" IS EVEN WORSE... so don't. Just... don't. We pay 6 figures a year for this product and "Go buy an ANOTHER add-on" is getting old, unaffordable and un-sustainable!

[Nic Brough -Adaptavist-]

>This is stated as though there could never be a need to change ownership. The number of reasons a person may want to change the ownership are not up to you. 

I am sorry, but you have completely missed the point.  There's no problem with changing ownership.  

The problem is that you are assuming that author = owner, and that's horribly wrong.

What you are suggesting here is that because the Disney group owns the Marvel stuff, they should be credited as the only author?  Expunging Stan Lee from all the history of actually writing a lot of it?  

And if you work in a regulated industry, it's usually illegal to change the author of something.  The person who did it needs to remain accountable.

You can't tell me that's the right thing to do.  The Author and the Owner are different things.

[William Wilson]

It seems my responses which legitimize my position keep getting (childishly) deleted, but it doesn't mean I'm going away. I'll keep speaking out against unprofessional behavior as required.

[Zack Howard]

There's definitely a need for this, despite Nic's irrelevant ramblings. 
For example, we're trying to migrate content from another wiki over to confluence using the REST API. However it is my understanding that the creator/owner/author of these pages is going to be whoever ran the request via the API. We don't want that, as that person is NOT the original owner of the documentation. We would want to retain the ownership from the original authors, or at least be able to modify the "created by" field so it shows the right person.

[Nic Brough -Adaptavist-]

I am not sure how it is irrelevant to be pointing out that creator/author is not the same thing as owner. 

Or that changing the creator/author is illegal in a lot more cases than people think!

[Zack Howard]

We've given two examples of why this is needed, and you've just given us whataboutery instead of addressing the actual issue or being helpful at all. Atlassian has hundreds of thousands of clients, each with their own use cases, but the prevailing trend with your comments is always "well that's not how I would do things so it's wrong". That's not what this community is for. This isn't a platform for debate. People are coming to you for your expertise and assistance. Be helpful. If you can't do that then maybe don't comment.

[William Wilson]

Nic,

If you were my father, you could determine what was in my best interest.

If you were my CEO, you could determine my policy. 

If I asked you for your opinion on policy, I'd be more open to it. 

If you listened (or read) what we were trying to tell you, we could have productive conversations. Especially since we gave you use cases, that (in my case) you conveniently deleted...

(I will screenshot EVERY post I make now, because if you do it again, I'm going to be reaching out to Atlassian directly about your behavior.)

In my case... the owner would be the same person, but the account would be migrated from a company we consolidated into our Azure tenant. And, you really have no right or responsibility to determine what is or is not legal for me to do.

Originally, the employees in my case, were able to log in with their SAMAccount ID. Now, they have to log in with their Azure email address, which has changed. The individual never changed. Only the account ID. But, you deleted that, because it undermined you.

So now, they (my users in discussion) don't have permission to manage their spaces any longer. Yes, they can still edit and "maintain" *some* of their old pages. And yes, I can update *some* settings to add NEW permissions. But It's also destructive to our reporting. 

That is wrong.

And you continue to gaslight people who are asking for help with your arrogant responses that demean and belittle people. It's bully behavior. If you disagree, you can confront me directly about it... I'd be happy to attempt to discuss it with you civilly. If you are willing. 

Otherwise... I'm not going away. I'll still be here with my opinions, and I will still be commenting on issues.

Remember. You always have the option to ignore me.

[Nic Brough -Adaptavist-]

I'm not trying to tell you that you are wrong, or even doing things that don't fit with the "Atlassian way".  My posts are an attempt to explain things that you do not appear to be understanding.  I am disappointed that you're not understanding it.  (But not surprised, I know I am not a good writer)

Could you explain what parts of "Confluence does not have an owner field" and "the author of a page is something you need to record, but does not imply the owner is that person" are different from my understanding?

[William Wilson]

Well... first... let me say thank you for the response. This is a really nice change. 

It's always a little frustrating when the other person is not understanding what you are trying to convey. It appears that frustration seems to be impacting both of us. And, while the internet is a great trove of information, it is often a poor communication medium.

Since you asked, I'd love to try to better explain my issue, and I will be heavily simplifying it for clarity... I can't speak for others.

In Jira server (on-prem), I had 2 people who owned Confluence spaces. Mary and Jim.

Mary is an employee of XYZ corp, and would log into Confluence with the username "Mary", and the email address "mary@xyz.com" which authenticated to a local AD.

Jim is an employee of ABC group. He was a member of our local AD policy, so he was able to log in with the name "Jim", and had an email address of "jim@abc.com"
We've now migrated to Atlassian Cloud. We are using Atlassian Access, Jira and Confluence.

In Atlassian Access we have an authentication policy that ties back to our AWS Azure IDP.

In Azure, Mary still has the email address "mary@xyz.com", and when she logs into Confluence, it recognizes her, and all the things she was connected to in confluence are still there for her.

However, when Jim tries to log in, he now has to use the email address "jim@xyz.com", because we have not done that tenant migration yet. PROBLEM. Jira and Confluence expect Jim to log in with "jim@abc.com" because Jira and Confluence are using Jim's old email address from his pre-migration account. So, when Atlassian looks to Azure to authenticate jim, it's using what it sees as NEW account information, because no account with the email address "jim@xyz.com" existed.

So, when Jim logs in, nothing he owns is tied to his account. Not his starred pages. Not his spaces. Nothing.

During the migration, we worked with Atlassian and a 3rd party Atlassian Migration partner to try to find a way to migrate the accounts over 'correctly'... and there was no solution. The final verdict by them was, "Well. I don't know what to say." Atlassian themselves could not manage to reasonably anticipate a situation where someone or several people's email addresses may have changed?

It begs the question... What would happen if our company changed their domain (maybe because of a purchase or whatever reason seems plausible), and subsequently, changed the email addresses for everyone in the organization?

I hope this explanation makes sense. Feel free to ask questions if it doesn't. It wasn't a simple situation to be involved in, it's not going to be a simple one to explain in a few paragraphs.

[Nic Brough -Adaptavist-]

Ok, so that's a problem with the user part of your migration.

It's not misunderstanding that "Author != Owner", you've had a migration go wrong.

[William Wilson]

No. It was never a misunderstanding on my end of how "Author != Owner". Or about how changing the actual human owner in corporate documentation *IS* in fact illegal in many cases. That is accepted as fact.

In this case, we don't want to change WHO owns items... we want to change the relationship between that person's 'old account', and their 'new account'. So that they still have all of their settings.

Page ownership be damned, they just want all their starred and personal spaces in Confluence, Boards and Filters in Jira and things like that back. 

---

It was a misunderstanding about how and when account information gets mangled... What the path to solve the problem is, and why.

In this particular case, one of several resolutions would be to simply change the asset/account relationship to the "new" user account, assuming the actual human remains the same owner. Effective, accurate and professional auditing should account for this, and any question of legality in changing documentation should be resolved. 

Another solution that would have worked, if someone had access to the data on the Atlassian side, would have been to change the email address that the internal user profiles were associated to. But I was told by an Atlassian rep during our migration, that solution was not an option.

I would have liked to do that (change email) on my side of things... but that is kind of the point of this whole complaint. I did not have that option on my end either. The email address of several hundred of our users had to change, and when we moved to the cloud, the need to log in with the new email address created duplicate accounts. The original accounts expected users to log in with their old email address, and Atlassian Access created new accounts for all the users whose email addresses changed, because Atlassian Access saw them all as new users, and did some wonderful magic, creating new accounts... (which, normally I would have been grateful for, if they were all new users) 

---

I really do want to thank you for circling back, and trying to fix our communication issues. I will adjust my own behavior to reflect the respect you've shown me with what I hope is equal respect for you. If you do feel that any of my future responses to you are out of line, please address it with me. 

For better or worse, it's clear you've invested a lot of time and effort into this community, that you are incredibly intelligent and talented, and that you are willing to settle into a more equitable exchange (when pressed). For those things, you have my respect and gratitude. 

[Zack Howard]

My use case is a bit different. I am trying to use automations and the REST API to let page owners know that their page needs updated. The issue is that some of these pages should have new owners because the original authors are no longer with the company. Confluence doesn't seem to have a value for most recent author, only the original owner (See screenshot). If I could switch the owner of a page or at least get a smart value for the most recent author this would solve the issue for me. 

[marc -Collabello--Phase Locked-]

Hi @Zack Howard ,

Confluence has the concept of the last editor of a page.  It is recorded with the page version information.  I'm not sure it is available for automations, but you can try. Our app Document Metadata can display this information.

[William Wilson]

Atlassian products by themselves are not inexpensive. I think people are getting REAL tired of having 90% of the solutions in these forums read as "There's yet ANOTHER paid add-on that you can add on top of the exorbitant pricing you are already paying." (even when it is as affordable as that add-on)

Which is not to say that marketplace providers should not get paid... it is more suggesting that perhaps, if Atlassian is offloading a great deal of it's development to the marketplace, that Atlassian should be lowering the cost of their core product(s).

[marc -Collabello--Phase Locked-]

Confluence also records the last user who edited a page.  This is kind of "the last author who contributed".

However this information is not directly visible for a user.  We have developed and app which allows you to show this last editor in your page or in a page properties macro: Document Metadata.

[Levente Szabo _Midori_]

With the recent introduction of the page owner feature in Confluence Cloud, it's important to be aware of its limitations:

1. Only one user can serve as the owner.
2. Bulk changes of ownership are not supported.
3. Transferring ownership can't be done independently without involving the current owner or an admin.
4. Directly targeting owners with automatic notifications is not an option.
5. Owners cannot be used in CQL searches.

For those seeking to elevate their page ownership experience, Better Content Archiving offers a more advanced Confluence page owner concept that not only overcomes these limitations but also includes a user-friendly macro for displaying pages owned by you or others, complete with page status details:

Learn about a better way to Confluence page owners >>

(Please note that Better Content Archiving is a free/paid, supported app and I'm part of the team developing it.)

[kc_ray]

The accepted answer is way off. Sure, there's a concept of the logged in user who created the page (object) in the first place and that has some legitimacy as an auditable facet of the page.. but add in Comala Workflows and you have a real problem.

The user creates the page, starts a workflow and then leaves the company - this is a huge problem with control of the workflow from then on, as it derives from the original page creator. 

Sure, you could say it's a fault with Comala, but it's just inheriting the ownership model from Confluence.

Possibly extending the page ownership paradigm to creator/maintainer would cover all bases.

The OP probably just needs to update the write permissions to the original page, but its a vague enough question to stoke this lovely skip fire in the replies :)

[Nic Brough -Adaptavist-]

I think you need to re-read the thread properly.

[Gary Sullivan]

Was this functionality briefly available yesterday?

[William Wilson]

Yes! It seems we got some traction on this. Thank you Atlassian team, @marc -Collabello--Phase Locked-  and @Nic Brough -Adaptavist- !

[Dan Liu]

This functionality does not seem to have appeared in the Confluence Cloud REST API yet. Is there a timeline for when Atlassian will support the change ownership feature in the REST API?