"Field field_last_password_reset is unknown" while importing configuration on site without password_policy activated

Facing same issue. Looks like problem is in updating users in password_policy_install()

$user
      ->set('field_last_password_reset', $timestamp)
      ->set('field_password_expiration', '0')
      ->save();

When using config import fields are not created at this moment.

This patch removes the install file and updates existing users with cron.

The password expiration boolean also needs to be set.

I'm not sure the approach in #5 is right, but I'm no config expert so happy to be corrected.

For now, as a temporary workaround, to deploy this through our dev/stage/prod environments, I added a hook_update call in one of our custom modules to install the module. drush updb should be called before drush cim, so this avoid the problem.

eg.

/**
 * Enable password_policy module.
 */
function my_custom_module_site_config_update_8006() {
  // Although config should cover this, if you rely on config alone, it throws
  // an exception during hook_install for password_policy, as the dependant
  // fields don't exist yet. @see https://www.drupal.org/node/2771129
  \Drupal::service('module_installer')->install(['password_policy'], TRUE);
}

Still an issue in 3.x-dev.

A better approach would be to remove the field_last_password_reset and field_password_expiration fields (and potentially any other config shipped by password_policy that doesn't make sense without the module around) in a new hook_uninstall for the module.

I believe this is related to a fundamental difference in core between enabling a module manually and importing it via config.

See #2766859: Module's config files are not installed during config import.

When a module is installed during configuration import, its default configuration from config/install is not imported. This is because config import is relying on settings that are in the sync directory. And those settings will not necessarily be available to hook_install.

It would be better to move the field definitions into hook_install if the are going to be required at that point during the installation process.

I would be happy to provide that patch.

Here is a patch that appears to resolve to error on my system.

Moving to needs review to kick off tests

Code review comments:

1. How does this behave upon uninstall? Do the fields remain? If so, we need to add a config dependency to password policy such that if the module gets uninstalled, the config does as well.

2. Looks like the patch in #10 does not apply cleanly. I think it's because of the header that the file starts with. The following code can likely be removed:

From cdeefa9c302ae7a6e7073a45410ea8b822669770 Mon Sep 17 00:00:00 2001
From: Melissa Bent <melissa.bent@mediacurrent.com>
Date: Thu, 23 Feb 2017 16:30:43 -0700
Subject: [PATCH] Move field generation from configuration files into
 hook_install in order to allow further processing on user entities.

---
 ...d.field.user.user.field_last_password_reset.yml | 26 -------
 ...d.field.user.user.field_password_expiration.yml | 26 -------
 ...ield.storage.user.field_last_password_reset.yml | 22 ------
 ...ield.storage.user.field_password_expiration.yml | 20 -----
 config/install/password_policy.settings.yml        |  0
 password_policy.install                            | 87 ++++++++++++++++++++++
 6 files changed, 87 insertions(+), 94 deletions(-)
 delete mode 100644 config/install/field.field.user.user.field_last_password_reset.yml
 delete mode 100644 config/install/field.field.user.user.field_password_expiration.yml
 delete mode 100644 config/install/field.storage.user.field_last_password_reset.yml
 delete mode 100644 config/install/field.storage.user.field_password_expiration.yml
 delete mode 100644 config/install/password_policy.settings.yml

Moving back to "needs work"

The patch applied cleanly for me against a copy of the latest 3.x-dev branch. I tested it both with composer-based patching and with manually applying the patch via the command line. Both times worked correctly.

The header of the patch file is not the issue.

Moving back to needs review.

There appears to be a file that was supposed to be removed and isn't.

Working on a new patch now. Stay tuned.

I took a different approach this time around. Based on the "TODO" in hook_install, offloading the setting of the initial field values was something that needed to be done anyway. So I moved that into a queue, preserving the provided YAML files.

I also added field clean up and queue clean up into a hook_uninstall which appears to be working well now.

Queueing patch for testing.

That wasn't a clean patch. Here's a better one.

Hiding bad patches and queueing for testing.

Fixed the tests by applying the same form display config to the test.

I like this approach a lot. Thanks to all of you that have contributed.

Code review comments on latest patch:

1. Seems to be a copy pasta error: "SalsifyContentImport" seems off to me in the patch.

2. The queue-based approach - does this deprecate the "cron_threshold" setting? Should we remove it? Can the threshold be configured into the queue somehow (annotation?).

3. Shouldn't items be added to the queue during hook_cron to continue to check for accounts that need their password reset? Or, is the queue only useful for install?

4. What is the timing ramifications? If a ton of existing users are added on module install, will there be a delay in which a user's reset config may not be set? Has this been tested?

Moving this back to "needs work" (notably for item 1 and for considerations of items 2-4)

@nerdstein

1. Definitely a copy and paste error. I borrowed from another module I'm currently working on to get the queue worker in place. Attaching a new, complete patch and interdiff.
2. At the moment the queue is only being run on install. This also helps speed along the module enabling process since it will not have to wait for the process to complete before moving forward. Additionally, we use composer for our deployments and this was causing significant delays on the system while we waited for the process to complete during deployment. It was better to offset it into a queue for performance. This does, however, introduce a _requirement_ for cron to be configured properly. It wouldn't be a bad thing to provide some integration with a cron helper like Ultimate Cron to aid in that process.
3. It would be a good idea to offset all of these checks into the queue system for sure.
4. For timing, the queue will process as many users as it can within a certain time limit. That time limit is set in the docblock on the queue worker. At this moment it's however many users it can process in 10 seconds. This is a great setting for threaded cron jobs. But it would probably be a good idea to up that value to something higher value, like 60 seconds. At that point the processing is based on the speed of the server. What this also does it provide some way for the system to reattempt processing a user's account if there is an error. This is not present in the current implementation.

This section in password_policy_cron bothers me still. This doesn't seem like a good way to go since it could cause memory errors just in loading all of those user account objects.

      // Load User Objects.
      $users = \Drupal::entityTypeManager()
        ->getStorage('user')
        ->loadMultiple($valid_list);

This could easily be thrown into a queue as well.

Here's a first look at that queue operation for cron jobs.

I also added a configuration form that allows it to be toggled on and off and allows the user to set the number of accounts to process per cron run.

Switching the existing cron implementation to use a queueing system should be a separate issue entirely, it has nothing to do with fixing the installation of the module.

Re the comment in #25 about cron, this has recently been fixed in #2836453: Cron hook exhausts memory when there is a large dataset of users, and I agree with #27 that the scope of this issue should be contained. Further follow-up issues can be created where necessary.

Sounds good to me.

Changing this to Needs Review to kick off testing.

Since the last test succeeded on the patch, could we get some people to test?

It would be great to get this into RTBC.

seems to fix my problem. thanks for the patch!

I had some difficulties applying the patch against latest stable because of missing comments, but the patch worked. My config imported and the module installed. Thanks for the work!

here's a reroll against latest dev.

Let's give this patch a go

The latest patch was successful for me.

The latest patch removes the queue worker classes from the patch. It still needs those queue workers in order to process the password policy queue.

I'm hoping to be able to update it later today unless someone else jumps in.

@merauluka, I took #27 as saying that the queue should be outside of this patch.

@robpowell, Ah. I see. I read it a bit differently. I had started moving a few other things into queues as well, but you're right. I believe #27 was talking about the queue system as a whole. I've create a feature request for that.

#2897274: Process initial password policy settings via Drupal queue system

@merauluka great I'll review when you get a patch ready.

A simpler solution is to create the fields with hook_entity_field_info() instead of config and leave the hook_install() update alone.

Updated patch includes an update handler to remove the existing field config.

Another possible approach without having to change the current fields and the user entity is skip the hook_install if is config is syncing (!\Drupal::isConfigSyncing()) and implement a new event subscriber for ConfigEvents::IMPORT to handle the new user fields values.

Here is the patch for #46

I can confirm the patch in #47 works for me, thanks for posting! I saw the similar pattern in another modules (e.g. lightning).

Re-rolled against latest 8.x-3.x-dev.

+ 1 to skip with isSyncing() approach as core modules (shortcut, forum) have it. In fact isSyncing() added for this reason.

+++ b/src/EventSubscriber/PasswordPolicyEventSubscriber.php
@@ -52,12 +54,43 @@ class PasswordPolicyEventSubscriber implements EventSubscriberInterface {
+  public function onConfigImport(ConfigImporterEvent $event) {

Wondering why just the fields reset part of hook_install here. If the module is getting enabled as part of config import, we wouldn't get the entity_form_display as well, no?

FWIW, I ran into this issue. Patch from 49 applied cleanly, but did not fix the error on config import. To fix, I disabled the module with drush, then flushed caches with drush and manually re-enabled the module from the Drupal admin UI. Ran config sync and everything is working now. Hope this helps someone down the road.

#49 works fine for me, thanks!

I can confirm that that path from #49 applied cleanly and fixed the problem.

I'm having the same issue as #51

FWIW, I ran into this issue. Patch from 49 applied cleanly, but did not fix the error on config import. To fix, I disabled the module with drush, then flushed caches with drush and manually re-enabled the module from the Drupal admin UI. Ran config sync and everything is working now. Hope this helps someone down the road.

+1 for #49. Ideally not the best solution, but bug is quite annoying and there is no workaround (so setting priority to major).

Worth mentioning doing this as a batch process will improve performances on website with lot of users. Also heads up for #2901418: Add hook_post_config_import_NAME after config import because when it's in we should improve this code again.

Wondering why just the fields reset part of hook_install here. If the module is getting enabled as part of config import, we wouldn't get the entity_form_display as well, no?

@vijaycs85 entity_form_display config entities will be nicely imported as part of the import process. We don't make use of them yet, so it doesn't matter the order they are installed in.

Couldn't reproduced the issue mentioned by #51 and #55.

Hi,

Patch in #49 didn't apply cleanly to latest 8.x-3.x-dev b/c of commit a96e772677761c68faf82734e45940afb1064fec

Here's a re-roll against latest dev.

All looks good. Thanks!

entity_form_display config entities will be nicely imported as part of the import process. We don't make use of them yet, so it doesn't matter the order they are installed in.

Thanks, @gambry. Let's get this in. +1 to RTBC.

Config import works without any errors after applying the patch from #57 . Thanks!

Latest patch works fine.

Config import works as expected after applying the patch from #57

On a large website with many users, I noticed that simply enabling password_policy locally takes FOREVER to complete and can lead to a WSOD.

Unfortunately, the patch in #57, although it fixes the Field field_last_password_reset is unknown issue, does not address/resolve this critical memory issue. CircleCi is unable to finish its job within the allocated memory and delivers a FAILED on every build, making it impossible to use this module. See error below.

[error] Drush command terminated abnormally due to an unrecoverable error.
Error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /home/circleci/my_project/docroot/core/lib/Drupal/Core/Cache/DatabaseBackend.php, line 167
Exited with code 255

On the other hand, the patch from #2897274: Process initial password policy settings via Drupal queue system fixes both of these issues.

Setting back to needs review in order to re-open the discussion and get some feedback/guidance.

Hi @bisonbleu, I think https://www.drupal.org/project/password_policy/issues/2897274 is already addressing this issue so this can be set back to RTBC as it's trying to fix another bug and not the low performance enhancement?

Hey @gambry, all good, I got my related/overlapping issues mixed up.

p.s. It is #2897274: Process initial password policy settings via Drupal queue system and #2983448: Refactor hook_install logic to expire passwords for existing users that are related and try to resolve the memory issue.

I used the patch from #57 which passed my Travis deploy to my development environment. However, when trying to do a configuration sync, on import, I get this error
InvalidArgumentException: Field field_password_expiration is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField() (line 586 of core/lib/Drupal/Core/Entity/ContentEntityBase.php)

Is this related? or a new issue?

@dallashudgens when enabling the module manually (or through drush/drupal console) the field is created as part of the installation process.
When the module is installed as part of config import, the relative config entities should be existing in the sync storage and so imported as part of the process.

Are field.field.user.user.field_password_expiration.yml and field.storage.user.user.field_password_expiration.yml in your sync folder?

I am using patch #49-D8 and looks fine so far.. thanks

+1 to RTBC on patch in #57; testing with 8.6.1, and it's the only way I can get a project that's managed with Acquia BLT to be able to be reinstalled from exported configuration.

The hook_install() in its current state assumes that you won't be reinstalling the module on a site built from existing configuration over and over again, and the patch in #57 seems to fix that assumption and allows me to reinstall my site as needed.

Here is an adaptation of the patch from #57 for the alpha3 version in case anyone else finds himself in the case.

RTBC++

Patch from #57 gets rid of the error message.
I'm a bit concerned about the possible performance impact by updating all users. Imagine sites with thousands of users.
I did not need the alpha3 version of the patch (see #70). I'm on alpha4.

Taken #70 for alpha4

I am having trouble getting the patch to apply in Composer. I keep getting "Invalid argument supplied for foreach() " even though patch 57 applies for me when I have 3x checked out. I am going to re-post the patch from a git diff to see if it makes a difference.

Thank you @drupalninja99: I experienced the same issue (composer install, drush cim, see "Field field_last_password_reset is unknown"), added your rerolled patch in #75, repeated, and all installed beautifully.

Compared #57 with #75 and all looks still good.
Running the tests to see if #75 applies nicely.

#75 passes tests now that we've fixed some other, unrelated causes of test failures. Needs review.

Another re-roll against current 8.x-3.x

Add test for scenario in summary

Reviewing #80 and #81.

1. Why is $timestamp set in a different way between hook_install() and onConfigImport()?

hook_install():
$timestamp = \Drupal::service("date.formatter")->format(\Drupal::time()->getRequestTime(), "custom", DATETIME_DATETIME_STORAGE_FORMAT, DATETIME_STORAGE_TIMEZONE);

onConfigImport():
$timestamp = gmdate(DATETIME_DATETIME_STORAGE_FORMAT, REQUEST_TIME);

2. When I attempt to run just the test provided by #81, I get an error. Am I doing something wrong?

There was 1 error:

1) Drupal\Tests\password_policy\Functional\ConfigImportTest::testConfigImportDisabledModule
InvalidArgumentException: Minimum requirement: driver://host/database

/var/www/html/drupal8/web/core/lib/Drupal/Core/Database/Connection.php:1515
/var/www/html/drupal8/web/core/lib/Drupal/Core/Database/Database.php:471
/var/www/html/drupal8/web/core/lib/Drupal/Core/Test/TestSetupTrait.php:164
/var/www/html/drupal8/web/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:615
/var/www/html/drupal8/web/core/tests/Drupal/Tests/BrowserTestBase.php:397

ERRORS!
Tests: 1, Assertions: 0, Errors: 1.

Hello,
actually the patch in #81 (and many of the previous ones) breaks the setup if made from configuration.
For example, if I set up my site with the config_installer profile, or if I enable the module by importing a configuration update where I add "password_policy" in core.extensions.yml, the setup will fail because it won't find the new fields.

The solution in #45, for example, seems to be better because it works in this scenario.

The following warning is reported by the DrupalPractice PHPCS standard for #80/#81:

\Drupal calls should be avoided in classes, use dependency injection instead

The offending line is:

$users = \Drupal::entityTypeManager()->getStorage('user')->loadMultiple();

I have removed the fields 'field_password_expiration' and 'field_last_password_rest' using drush first and the import succeeded.

Use drush eval 'field_delete_field("field_password_expiration")' and drush eval 'field_delete_field("field_last_password_rest")' to remove the fields and then run drush config-import.

Here is a re-rolled patch based on : https://www.drupal.org/project/password_policy/issues/2771129#comment-12...

EDIT: Please ignore this patch.

/**
 * Implements hook_update_N().
 *
 * Deletes the last password and password expiration fields.
 */
function password_policy_update_8202() {

  $field_config = \Drupal::getContainer()->get('entity_type.manager')->getStorage('field_config');
  $field_config->delete($field_config->loadMultiple([
    'user.user.field_last_password_reset',
    'user.user.field_password_expiration',
  ]));
}

Running this hook_update and then doing drush cim saved my world.

I'd advocate for a version of the patch from comment 45. Though any data in the existing fields should be migrated into the new base fields.

As navneet0693 says, DB updates must be run before any config import. For anyone installing from config, that config must be exported from a source installation after DB updates are run too. This is standard practise for any config management - the database needs to be in the right shape before any import/export config operations are run. Otherwise Drupal cannot rely on its known schema for config.

Other approaches that install the existing fields when password_policy is installed, need to ensure the fields are correctly uninstalled when the module is uninstalled too. I haven't seen a working version of that yet either.

Reroll patch from #81 for latest Dev (8.x-3.x was updated on 28 Jun 2019)

Created this for alpha5 based on last patches.

updated patch

I rerolled the patch, and fixed some minor coding standards issues.

Versus #94:
- Committed unrelated hook_update_N() documentation fix: https://git.drupalcode.org/project/password_policy/commit/de2b0e9. (Thanks, Damien.)
- Removed some trailing whitespace.

"Needs work" because this patch introduces a PHP_CodeSniffer warning (per #84):

FILE: /var/www/html/drupal8/web/modules/contrib/password_policy/src/EventSubscriber/PasswordPolicyEventSubscriber.php
---------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
---------------------------------------------------------------------------------------------------------------------
 88 | WARNING | \Drupal calls should be avoided in classes, use dependency injection instead
---------------------------------------------------------------------------------------------------------------------

Marking critical as a note to get this in the next release.

I've been applying @anairamzap patch for a couple times already... any timeline on when this gets released?

tomasdev, thanks for reporting that the patch is working for you. The patch in #94 has at least one issue and still needs work per #95.

I don't think this is a good idea:

+    // @todo Get rid of updating all users.
+    foreach ($users as $user) {
+      if ($user->getAccountName() == NULL) {
+        continue;
+      }
+      $user
+        ->set('field_last_password_reset', $timestamp)
+        ->set('field_password_expiration', '0')
+        ->save();
+    }

On complex sites with many users this operation can take a very long time, I can imagine 30 minutes or more. This would increase the downtime too much for deployments. More likely even, this would cause the process to run out of memory, causing the deployment to fail with a fatal error.

A better way to approach this is to perform a simple update query, which will take care of this operation in less than a second even if there are hundreds of thousands of users.

Patch in #95 works but is based on the 8.x-3.x branch and doesn't match with the 3.0.0-alpha5 module version code (latest release so far) Updating this patch to be applied to 8.x-3.0-alpha5.

Patches are always against the latest dev version. If you want to re-roll it to apply to a specific release, you're certainly welcome to do so and post here for others who might want it, but the latest patch against dev in #95 should still be the one shown on this issue until a newer patch against dev which addresses any outstanding concerns (like @pfrenssen's in #99) is provided.

I can confirm that the patch has some whitespace issues...

 [info] Executing: mysql --defaults-file=/tmp/drush_kf886E --database=default --host=db --port=3306 --silent -A < /tmp/drush_SkALS9 [2.12 sec, 10.44 MB]
 [info] Installing from existing config at /var/www/config/default [2.36 sec, 10.43 MB]
 [notice] Starting Drupal installation. This takes a while. [2.36 sec, 10.43 MB]
 [debug] Calling install_drupal(Composer\Autoload\ClassLoader, array) [2.36 sec, 11.29 MB]
ParseError: syntax error, unexpected ''' in /var/www/docroot/profiles/custom/webny/modules/contrib/password_policy/password_policy.install on line 64 #0 /var/www/docroot/core/includes/install.core.inc(2074): drupal_check_profile('my_secret_profile')

In this patch provided fix for failed apply from #100

Trying to fix my latest failed patch

#104 still had the following error message while #95 was successful on a drush site-install with config imported from a profile.
InvalidArgumentException: Field field_last_password_reset is unknown. [error]

Status is already "needs work".

Same here. On installing from config with drush it still throws the same error.

Patch #95 is the correct one to use for now.

#2983448: Refactor hook_install logic to expire passwords for existing users has a patch that would resolve this as it removes the user stuff from Password Policy's install hook. Adding it as related.

If, like me, you need a hot patch for password_policy 8.x-3.0-alpha4 because your stuck to ctools 8.x-3.0 for the moment, then this is the patch to use

Here's an updated patch against current dev that fixes the outstanding use of \Drupal.

+++ b/src/EventSubscriber/PasswordPolicyEventSubscriber.php
@@ -68,6 +70,35 @@ class PasswordPolicyEventSubscriber implements EventSubscriberInterface {
+    $timestamp = gmdate(DATETIME_DATETIME_STORAGE_FORMAT, REQUEST_TIME);

DATETIME_DATETIME_STORAGE_FORMAT is deprecated and should not be used anymore

See #2983448: Refactor hook_install logic to expire passwords for existing users for a patch that also resolves this issue and does not use gmdate or deprecated global constants.

We should block work on this until #2983448: Refactor hook_install logic to expire passwords for existing users is fixed. We are duplicating code from the install hook which has a performance issue. This code is being removed in that issue. Let's pick this back up once the install hook is cleaned up so we don't risk to reintroduce the performance issue.

Patch updated to fix DATETIME_DATETIME_STORAGE_FORMAT and REQUEST_TIME deprecations.

I'm marking this as fixed thanks to the work performed in #2983448, comment 21 which had overlap and has been merged.

Giving everyone credit for all of their contributions to this longstanding issue. Thanks

@nerdstein On current dev branch I'm still getting the error when installing a site from a config export directory. This patch is fixing the issue for me so I believe this might still be needed.

Same as @piggito I ran into this error when installing from config. Patch #114 worked for me.

Same as @PCate and @piggito. Ran into this issue while attempting to import config on a new environment. The patch in #114 worked for me.

Confirming that patch #114 works.

I can't get this to apply with Composer, am I doing something wrong?

"extra": {
        "composer-exit-on-patch-failure": true,
        "patchLevel": {
            "drupal/core": "-p2"
        },
        "drupal-scaffold": {
            "locations": {
                "web-root": "web/"
            },
            "file-mapping": {
                "[web-root]/.htaccess": false,
                "[web-root]/sites/development.services.yml": false
            }
        },
        "installer-paths": {
            "web/core": ["type:drupal-core"],
            "web/libraries/{$name}": ["type:drupal-library"],
            "web/modules/contrib/{$name}": ["type:drupal-module"],
            "web/profiles/contrib/{$name}": ["type:drupal-profile"],
            "web/themes/contrib/{$name}": ["type:drupal-theme"],
            "drush/Commands/contrib/{$name}": ["type:drupal-drush"]
        },
        "patches": {
            "drupal/password_policy": "https://www.drupal.org/files/issues/2020-07-03/2771129-114.patch"
        }
    }

results in

Invalid argument supplied for foreach()

@rkent_87: Inside the patches array, each package is the key for an array of patches, like so:

"patches": {
    "drupal/password_policy": {
        "description for patch 1": "https://www.drupal.org/files/issues/2020-07-03/2771129-114.patch",
        "description for patch 2": "https://www.drupal.org/files/issues/foo/bar-1.patch"
    }
}

Sorry to open a new PR. I tried to use beta1 but apparently, it did not include the patch from #2983448.
Note, that this is fixed in the dev version.

Thank you, for this fix
Waiting for a release.
I hope soon

Patch from #114 works for me with beta1 too. thanks!

Patch for https://www.drupal.org/project/password_policy/releases/8.x-3.0-beta1 release.

Reriolled against 3.0 release

I tried upgrading to 3.0 and got this error:

> Fatal error: Uncaught Error: Class 'Drupal\password_policy\EventSubscriber\ConfigEvents' not found in /var/www/docroot/profiles/custom/webny/modules/contrib/password_policy/src/EventSubscriber/PasswordPolicyEventSubscriber.php:125

I hunted around for fragments of this error until I found this issue. I had removed the old password_policy patch because it wouldn't apply. I assumed it had been rolled into the full release since it was so old. Still, I decided to try applying the most recent version of this patch and re-running the update. It worked.

I wouldn't say this is "fixed". I recommend rolling this into your 3.1 whenever that happens.

Hi I am still getting below error for 8.x-3.0. #130 patch did not worked for me.

Drupal\Core\Entity\EntityStorageException: Field field_last_password_reset is unknown. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save()

I get this error while adding new user.

@saurabh.tripathi.cs

I was getting the same error whenever I created a new user and when the user updated their own password. I fixed it by running "drush updb". Figured out the issue after looking at this bug https://www.drupal.org/project/password_policy/issues/3236417

The version of patch 130 is no longer applicable for the latest version of module drupal/password_policy [3.2].
I updated the patch for the new version.

Sorry :(.
I have a problem updating comments with the correct number of the version of the file :).

Patch #135 had a lot of code style errors (4 tabs instead of 2), added interdiff between old #130 & previous #135 patches to check errors.
Rerolled #130 patch against 8.x-3.2.

please review MR-44, here is the patch for the same.

updated patch with submodule coverage

Will these patches work for password_policy 4.0?

There no "Drupal 4.0", as far as you should be concerned, the Drupal core 4.0.0 release is from 2005.

I think this issue should be left "closed' and a new issue opened if the problem still exists in 8.x-3.x or 4.0.0.

Echoing @DamienMcKenna's comment that a *new* issue should be created if this is still a problem as this one is marked closed/fixed. Thanks. You can link to this one.