Bug confirmed.

The reinitialisation of the password is asked first in the modal which displays the whole site page.

@mbabker

TBH I don't know if there's a fix for this without shoving in a new plugin event. The password reset required redirect is done inside a helper method in the application classes that is based on a whitelisted set of components, layouts, and tasks. Putting the logic in there to determine the privacy policy article doesn't fly because that is determined with plugins and for the love of all that is sane please do not put anymore hardcoded plugin references in the libraries API unless you move that code out of plugins and into a library class.

So, fixing it constitutes a new feature (a onPasswordResetRequiredRedirect event, or something adequately named), meaning work on it in 4.0.

Just a very nasty-hasty workaround, the basic idea and not more, that we use for two Joomla 3 sites at the moment with many new users that have to reset their password.
An override of com_users/profile/edit.php.
All I do is hiding the original label of the privacy field when requireReset is active for a user
and replacing it with a link to a static HTML page that is located on another domain.
Could be better but is sufficient for our requirements and laziness at the moment.
https://github.com/GHSVS-de/GHSVSThings/blob/master/relaterquatch/com_users-profile-edit.php#L69-L92

Many thanks for the replies. I understand this is not an easy fix and will work around the issue until 4.0

Changed Issue for J4.

Some possible workarounds for 3.x, done in the Privacy Consent plugin:

1. Disable privacy checkbox if password reset is required. The user would have to edit the profile twice. First to reset the password and then to provide consent.

2. Disable password reset requirement while on privacy article page. But maybe this would be a security risk,

Disable password reset requirement while on privacy article page. But maybe this would be a security risk

That's the bit that requires the plugin event unless you're going to hardcode the core plugin that manages that privacy policy bit into the application class, which goes against the design of com_privacy (intentionally the policy article is managed at the plugin level to not force it to be in com_content and to have not duplicated com_content's article logic into com_privacy (including all of the backend management and frontend routing and display), so if someone using K2 or EasyBlog or any other content creating component wanted to put their article in their chosen content component they just need a plugin supporting the hook) and just adds yet another hardcoded plugin reference to the core libraries.

I have the same problem, but i have today created a override for the label.php in the layout.
layouts\plugins\system\privacyconsent\label.php

This loads the content selected in the plugin, including modules, iframe, etc.

In addition, a language string "PLG_SYSTEM_PRIVACYCONSENT_READ" must be created here, which is displayed as a button at the bottom of the modal window. This can be "OK", "read", "understood" or similar.

Whether this fits with K2 or similar extensions, I can not determine, because I do not use this.

This is a screenshot with the protostar template. Joomla 3.9.15

I will give my override the to the https://j-over.de