Migration commits repository transaction wrong user

[wizhippo]

On https://github.com/kaliop-uk/ezmigrationbundle/blob/master/Core/MigrationService.php#L221 this can cause an exception as the commit may need read access to objects. At this point the user could be anonymous and not have read rights as the RepositoryExecuter resets the user.

This can be replicated by running the following migration on a clean install

https://gist.github.com/wizhippo/d549e03a6615f05122763f259ebfd383

Guess repository transactions are user sensitive.

In this case during the commit the PublishVersion signal dispatches a cache clear which in turn tries to load the content info. Since we are now anonymous it fails.

[gggeek]

Thx for the test case - I think the pointer to line 22 in MigrationService might be wrong :-)

[wizhippo]

Corrected. Should have been line 221

[gggeek]

Your snippet does work in 5.4 and lower!

It seems like the concept of what a 'repository transaction' is, and what is hooked up to it, might have changed across versions of eZ5/eZ6.
As if not having support for nested transactions was not bad enough...

The good news is: you can use the existing flag to omit transactions, and your migration will succeed.

The bad news is: if we want to fix this in a better way, we would need to set the repository-user per-migration, in the migration service, and stop doing it per-step, in the step executors. It will be hard to achieve that without any BC breackage. I wonder which release would be best suited to introduce this change (3 or maybe 4 ?)

[gggeek]

Btw, I created an issue in eZ: https://jira.ez.no/browse/EZP-26407

[gggeek]

ps: "it seems" that the above scenario might apply as well when there are legacy workflows involved, on an ez 5.4 kernel.
So definitely something to tackle...

[wizhippo]

Thanks for looking into this more and posting the issue on jira

[gggeek]

Most likely related to #78

[gggeek]

I opted for an ugly but minor change: 'become admin' just around the call to repo->commit. This should fix the symptoms for the moment.
For the future: make it possible to choose the 'admin' user to use

[gggeek]

Fixed in 2.4 & 3.0beta2