Migrate the existing values of a password property when its storage type changes

Problem

Changing the storage type of a password property (from the class editor, or when an extension changes the definition of its class) doesn't change the values already stored in the objects of that class:

• Clear to Hash: the existing values stay in clear text in the database, in backups and in exports. Since XWIKI-25752 they can still be checked, but each check logs a warning saying they should be hashed or reset.
• Hash to Clear: the existing values stay hashed and can no longer be checked against the original password.

The administrator has no way to know how many values are affected, nor to say what should happen to them.

Proposal

When the storage type of a password property changes, handle the existing values of that property in all the objects of the class, according to one of the following choices:

• Keep: don't touch the values (current behavior). A warning is logged with the number of values left in the previous format.
• Hash: hash the clear values with the hash algorithm of the property (Clear to Hash only, since a hash can't be turned back into the original value). Users and clients keep using the same password.
• Remove: remove the values. This is the only way to make the old values useless, since the previous revisions of the documents (document history) still contain them. Users or clients then have to set the value again (password reset, new token, etc.).

The choice isn't stored in the class: it only applies to the storage type change being saved.

Class editor

When saving a class in which the storage type of a password property changed, the class editor asks the administrator what to do with the existing values, showing how many there are and the choices allowed for that change.

Other changes

When the storage type changes without an explicit choice (script, XAR import, extension upgrade, request without JavaScript), the values are kept and a warning is logged.

Execution

• Run the migration as a background job, in batches, since a class can have objects in many documents.
• Only update the documents that the author of the class change is allowed to edit, and log the other ones.
• Save the updated documents as minor edits, with a comment explaining the change.

Open questions

• How can an extension declare what to do with the existing values when a new version changes the storage type of a password property of its classes (e.g. remove generated tokens, hash user passwords)?
• Should the job progress be displayed in the class editor after the save?