Upgrade 

What changed 

The submitted usergroup relation is now validated on the server before the user is persisted, in a single place (UserGroupSanitizationService). The form is secure by default / fail closed:

• Forced groups - if settings.<form>.overrideUserGroup is set, the configured group(s) always win and the submitted value is ignored (unchanged behaviour).
• Field not editable - if usergroup is not part of the configured fields, any submitted usergroup change is reverted.
• Allowlist - if settings.<form>.validation.usergroup.inList is set, the submitted uids are reduced to that list. This is the recommended way to let users choose a group.
• Opt-in for unrestricted selection - if no allowlist is configured but settings.<form>.misc.allowUnrestrictedUserGroupSelection = 1 is set, every offered group may be selected (legacy behaviour).
• Fail closed - if neither an allowlist nor the opt-in is configured, the submitted usergroup change is ignored and a log entry (Profile update not authorized) is written.

Every reverted or reduced submission is logged so unexpected usergroup changes become visible.

Customized usergroup templates 

If you override Resources/Private/Partials/Fields/Usergroup.html, note that the field is now rendered depending on the new usergroupFieldMode variable (select / hidden / notice). When neither an allowlist nor the opt-in is configured, a generic notice (usergroupSelectionNotConfigured) is shown instead of the selection; the specific missing configuration is not exposed in the frontend but written to the TYPO3 log. Compare your template with the shipped partial to pick up this behaviour.

See Securing the usergroup selection for the full description of the feature.

What changed 

• A dedicated adminHash is now mandatory for every admin action. HashUtility can now derive a separate admin hash for a user, and admin confirmation, refusal and silent refusal always require a valid adminHash. The regular user hash alone is no longer sufficient. This applies both to the registration confirmation (New controller) and to the profile change confirmation (Edit controller, confirmUpdateRequest).
• The required confirmation is stored on the user. During registration femanager now persists which confirmations are required (user and/or admin) in the new field fe_users.tx_femanager_confirmation_required. The workflow reads this field instead of the ambient plugin settings, which the "Resend Confirmation Mail" plugin does not have access to.
• Resend only resends a pending user confirmation. The resend action sends the user confirmation email only when the account still has an outstanding user confirmation (already confirmed accounts, or accounts that only await admin approval, are not resent). To avoid disclosing whether an account exists for a given email address, the same neutral message is shown for every valid address - regardless of whether a mail was sent, nothing was pending, or no such account exists.

Customized email templates 

If you override any of these templates, add the adminHash argument to all admin action links, otherwise the links will be rejected as "not authorized":

• Resources/Private/Templates/Email/CreateAdminConfirmation.html
• Resources/Private/Templates/Email/CreateNotify.html
• Resources/Private/Templates/Email/UpdateRequest.html

Example:

old: <f:link.action action="confirmCreateRequest" controller="New" absolute="1" arguments="{user:user, hash:hash, status:'adminConfirmation'}">
new: <f:link.action action="confirmCreateRequest" controller="New" absolute="1" arguments="{user:user, hash:hash, adminHash:adminHash, status:'adminConfirmation'}">

Fallback if the upgrade wizard is not run 

The fix does not depend on the wizard for its security: for accounts that still have the default value 0 (none) - i.e. accounts created before the field existed - the required confirmation is inferred at runtime from the confirmation state, mirroring the wizard:

• disabled, confirmed by user, not by admin → admin confirmation is still required
• disabled, confirmed by neither → both confirmations are required (an admin can always release the account from the backend)
• already confirmed by admin, or enabled → no confirmation pending

As a result the registration workflow and the resend action behave correctly even without the wizard. Running the wizard is still recommended: it persists the precise requirement so it is shown and filterable in the backend and the runtime fallback is no longer needed.

What changed 

The user shown by the Detail plugin is now resolved from a trusted source:

• If a specific user is configured, request arguments can no longer override that user.
• If Logged in FE User ([this]) is configured, request arguments can no longer override the current user.
• Links generated by the List plugin contain a signed hash for the linked user. The detail action rejects a request-supplied user when the hash is missing or invalid.

Customized list templates 

UserController::listAction assigns the showHashes array, keyed by the user uid. Resolve the nested value in a separate Fluid variable before passing it to arguments.

Old:

<f:link.action action="show" arguments="{user:user}">
   {user.username}
</f:link.action>

New:

<f:for each="{users}" as="user">
   <f:variable name="showHash" value="{showHashes.{user.uid}}" />
   <f:link.action action="show" arguments="{user:user, hash:showHash}">
      {user.username}
   </f:link.action>
</f:for>

Do not use hash:showHashes.{user.uid} directly inside the arguments expression. With the Fluid version used by this release, the nested expression can be interpreted as a string instead of an array.

Customized detail templates 

If a customized Resources/Private/Templates/User/Show.html contains a self-referencing show link, pass the showHash variable assigned by the controller:

<f:link.action action="show" arguments="{user:user, hash:showHash}">
   {user.username}
</f:link.action>

See Show and List Frontend Users for the full description of the List and Detail views.