Problem/Motivation

#2953111: Only migrate role permissions that exist on the destination change the Role entity to emit an exception on a non-existent permission. It added a post update to fix roles. The problem is that post updates are supposed to run on a working system. But if this update has not taken place then any other post update cannot edit and save a role - this causes problems.

Steps to reproduce

Add post update to a module that comes before user... it will break if this update has not already run.

Proposed resolution

Move this update to hook_update_N
Add this post update to the removed list? Do we need to do that give 10.0.x is not out yet?

Remaining tasks

tbd

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

TBD

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alexpott created an issue. See original summary.

alexpott’s picture

Status: Active » Needs review
FileSize
4.49 KB

We already have test coverage in \Drupal\Tests\user\Functional\Update\UserUpdateRoleMigrateTest - I'm not sure that we need to batch these updates like I doubt that there are sites with more than a few hundred roles and we shouldn't be scared of a couple of hundred of updates. And this would be a very very very extreme case.

larowlan’s picture

Yeah I'd be dubious of any site with 100 roles, they would have bigger problems than update hook batching

larowlan’s picture

Status: Needs review » Reviewed & tested by the community
alexpott’s picture

Discussed with @catch we agreed to add a comment to user.install saying the D10 has a new update so adding one here is not recommended.

alexpott’s picture

+++ b/core/modules/user/user.post_update.php
@@ -18,39 +14,3 @@ function user_removed_post_updates() {
-/**
- * Remove non-existent permissions created by migrations.
- */
-function user_post_update_update_migrated_roles_followup(&$sandbox = NULL) {

Do we need to add this to the list of removed updates? Or do we need to have it as an empty function? This has been released in a beta...

catch’s picture

We can't add it to removed updates - would prevent sites that haven't updated to the beta from updating. We could leave a stub though.

alexpott’s picture

Discussed with @catch and @longwave. @longwave pointed out that we'd removed an update during a beta before - see #3145501: updb error processMultivalueBaseFieldHandler() - I think this is okay tbh and cleaner than leaving an empty stub that people are going to see when updating to D10.

  • catch committed 806be29 on 10.0.x
    Issue #3319845 by alexpott, larowlan, catch:...
  • catch committed 87932fe on 10.1.x
    Issue #3319845 by alexpott, larowlan, catch:...
  • catch committed ca62184 on 9.5.x
    Issue #3319845 by alexpott, larowlan, catch:...
catch’s picture

Status: Reviewed & tested by the community » Closed (cannot reproduce)

So this means we really don't want to add any updates to user in 9.5.x from now onwards, however we can still add them to system for now if we have to and the comment in the 9.5.x patch is a good reminder.

The update switches from config entities to raw config API which is very much needed. The exception throwing is a good reason to move this to hook_update_N(), it's not quite a schema change but it's close.

Worst case that happens with just removing the post update is that sites already on the beta will have that update as cruft in their record of post updates, but this won't cause them any issues so don't think we need to do anything extra to support beta-beta/beta-rc updates.

Committed/pushed to 10.1.x and cherry-picked to 10.0.x, and the comment-only patch to 9.5,x thanks!

catch’s picture

Version: 10.0.x-dev » 9.5.x-dev
Status: Closed (cannot reproduce) » Fixed

Status field went completely wrong..

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.