For some reason I can’t get the user:identity mappings anymore. My migration development worked quite reasonably 1-2 weeks ago, but then I had some more urgent things to attend to and now I had time to return to this and was surprised to see that my migration code doesn’t work anymore and reason seems to be that I can’t get any user server->cloud mapping information like I did 1-2 weeks ago.
So my call looks like this:
{
“method”:“GET”,
“path”:"/rest/atlassian-connect/1/migration/mapping/301a5ae1-ec6f-3381-b51f-57cee4a1a40d/page",
“query”:{
“namespace”:“identity:user”,
“pageSize”:100
},
“headers”:{“Content-Type”:“application/json”}
}
But the return is only this:
{“meta”:{“pageSize”:100,“hasNext”:false,“lastEntity”:null},“items”:{}}
My local Confluence Server has only the admin-user and I see that user (name PepikM, but same email) being migrated to Confluence Cloud along with the rest of my data. And I do get a webhook-event that has the transferId I’m using above:
…
transferId: ‘301a5ae1-ec6f-3381-b51f-57cee4a1a40d’,
…
So what might have happened here? Shouldn’t it be possible to retry the migration as many times as I need, maybe deleting the migrated test-space as well as the migrated “PepikM” user every time before running test migration again? I know that there is 5 day time-limit for retaining the user-mappings on the cloud but AFAIU, that only concerns a single migration run and single transferId.
I absolutely need to know the mapping between userID values between Server and Cloud so this is a show-stopper to our automatic migration development unless resolved.
Hi @PetriJuhaniRiipinen,
How are you re-running your migration? Are you using the REST endpoint documented here:
because this will not resend/update any user mappings or core data. It only runs app migrations.
Each transferId is mapped internally to all the previous migrations between that server and cloud instance with a migrationScopeId, and if this changes then the mappings are disconnected. I don’t think this happened here because I’m seeing results going back about 30 days.
You say that
My local Confluence Server has only the admin-user
so I’m trying to understand where did the other users come from that you’re expecting to find?
Looking at the logs, I can see the transfers for 16/April/2021 and 19/April/2021, and I can only see 2 identity:user mappings were saved. There were no updates since then, so yes, the identity:user mappings will have been removed as they are older than 5 days.
We’ve been discussing internally about what happens if a customer does their core data migration and then later (after the 5 days) does an app migration, will that app migration be able to see the user mapping data. I don’t have an answer for that yet.
Regards,
James.
Hi @jrichards,
Ok, that is a new page to me, so looks like that is the issue. I’ve not used that “re-run” information before.
I only have the one default admin user in my Server-instance so I’m expecting to see only that user on the Cloud-side as well and that did happen before.
I think the problem is exactly that as you mention on the last paragraph. But that’s exactly what happens with the local development environment as one keeps developing, testing and running migrations tens of times over the span of multiple days / weeks, not being able to work on this constantly etc.
But thanks for the link, I’ll have a look at that, it will probably fix this issue.
Well, looks like it’s not really working. I can now re-run the migration easily with the curl request shown on that page, and I do get callback to my Cloud-backend webhook, but the user-mappings still won’t appear there so can’t really map our migrated data to Cloud users.
Oh, blind me: you did write that this only runs our custom migrations so sure, no users expected to even appear there. But this doesn’t help me much with this case before I can get user mappings there again.
So basically I’m still blocked from progressing…
Ok, got an idea: Is the migrationScopeId tied to particular Server - Cloud pair? So what if I abandon my current dev-site and create a new dev-site and then migrate to that, would that create new migrationScopeId and thus create the user-mappings again?
Yes.
I recommend that for testing you try and reproduce the end user experience as much as possible. I’m not sure how your dev sites are set up, but either re-create the server side, or create a new cloud test site and reconnect and do a full users/spaces/app data migration once at the beginning and then confirm the user mappings exist with the transferId.
But in general, you need
- Dark feature set, see How automated migration works | App migration platform
- Cloud and Server keys set correctly in the
get*() methods in the AppCloudMigrationListenerV1 interface
- Choose your app in the App Assessment as Needed in Cloud
- Ensure you have the
MIGRATION_TRACING_IDENTITY scope defined
If it’s still an issue, we can have a call and we can walk though your code and example.
Thanks.
Hi @jrichards
Well, I did the following:
- Verified that everything on my setup is according to what you wrote.
- Created a new Cloud Bundle Dev-site (petridev3.atlassian.net)
- Created a new migration from my local Confluence Server to the new Confluence Cloud site and ran it with transferId = ad6ed7a8-71e2-3eed-a3fc-6c1ce6eae827
So according to your reply, the user mappings should have now been created again because the migrationScope-identifier changed because of the new cloud-site, right? Well, that didn’t happen. I do see from the Cloud site that the users have been transferred there, but I still can’t get the user mappings for them.
Note that this was the full-migration from the Confluence Server Admin page, not the re-run app migration with curl. I understand that the re-run with curl would not create the user-mappings, but that’s not the case here.
What to try next?
Hi @PetriJuhaniRiipinen,
I had a look for transferId = ad6ed7a8-71e2-3eed-a3fc-6c1ce6eae827 and I can only see one user in the identity:user mapping. I’ll assume that’s the admin user.
If you chose users and groups then I would expect them all to be migrated across and if you chose only users in the space then just those users should be sent.
It’s not really clear what’s happening, so I’ll reach out to you via the Marketplace team and try and set up a meeting.
Regards,
James.
1 Like
Hi @PetriJuhaniRiipinen ,
Are you still facing issues in accessing identity:user mapping ?
Thanks and regards,
Hariharan.
Hi @HariharanRajendran ,
Well, just to confirm I did the following test:
- Created new site to start from fresh (petridev4.atlassian.net)
- On the server I created one test space, 3 test uses and couple of pages for each user with some diagrams on the pages. Each of the 3 users
- Then I ran app assessment and the migration with transferId: db4edbdb-d032-3eea-ba49-5b5773d30397
On the webhook callback code I try to get all user mappings but I get no data.
This is the request:
{"method":"GET", "path":"/rest/atlassian-connect/1/migration/mapping/db4edbdb-d032-3eea-ba49-5b5773d30397/page", "query":{"namespace":"identity:user","pageSize":100}, "headers":{"Content-Type":"application/json"}}
And this is the response:
{"meta":{"pageSize":100,"hasNext":false,"lastEntity":null},"items":{}}
So yes, I am still facing issues and my progress is totally blocked until I can get the user mappings as we have external data that needs to be mapped from Server user to Cloud user, otherwise we can’t implement the automated migration.
Regards,
Hello @PetriJuhaniRiipinen,
I checked the transferId db4edbdb-d032-3eea-ba49-5b5773d30397 and I got the same conclusion @jrichards had.
It seems no users were selected to be migrated on that migration plan.
By checking the logs I could see mappings being created for confluence:page but not for identity:user. This is the expected behaviour for migrations that are “spaces only”.
Could you please double check the selections you are making while generating the plan on CCMA? It’s in a step before the pre-flight checks are executed.
Thank you!
Andre
Hello @AndreRosot ,
Ok, here are my initial options:
I have created 3 users to server and those 3 users all have two pages under a single space and I want to migrate that space, along with those 3 users and their 6 pages with all their attachments. All those users are “related to the selected spaces” in that they all have pages under the space that I will select.
On the next page I choose the space to migrate:
And this is the final review:
And then I run this (transferId a07ee9c4-c0dd-37d5-90d7-9b75f7a87cbc).
On the server I have initially these users:
And when checking the Cloud, I see these users migrated there (only I was there before the migration):
So, clearly four users where migrated from Server to Cloud:
So I think it’s reasonable to expect mappings for all those four users from Server to Cloud to exists. Or am I misunderstanding something? I don’t want to migrate all users at this point, only those that are somehow related to my “Migrate”-space? Is that not possible so that one would get the user mappings at the same time?
Of course again no user-mappings:
{"meta":{"pageSize":100,"hasNext":false,"lastEntity":null},"items":{}}
Regards
Hi again, @AndreRosot ,
Ok, looks like that when I selected “All users and groups from the Confluence directory”-option on the migration configuration, the users mappings were indeed generated! So I guess that solves my problem!
Thanks,
