This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).
This adds support for optional policies to the user acceptance reports.
Distinguished are "Pending" acceptances (we did not hear yet) from
"Declined" (user did not agree). The status workflow updated to support
new transitions: pending -> declined and declined -> accepted.
For optional policies, we provide a radio selector to let the user
choose the acceptance status on the consent page. For policies displayed
on their own page, we display a link to decline the policy.
The way how we pass the list of policy version ids to index.php has
changed so that we can now not only pass the list of ids, but also the
actual acceptance status (accepted / declined).
This method allows to quickly check if the given policy version is
marked as optional or compulsory. This will be needed in other places
such as permissions check.
The method now returns three-state logic. A bool value true/false is
returned if the user has accepted/rejected the policy, respectively. A
null value is returned if the user did not express their agreement in
either way yet.
This allows to distinguish between "rejected the policy" and "did not
say anything about it yet" cases.
The policies can be revoked by clicking the "Agreed [on behalf]" ticks.
A message has been added also to explain users they must contact to
the DPO if they want to withdraw their consent to policies.
Avoid redirection for accepting new policies during the manager user session
when $user->policyagreed=0 and he/she activates the first policy for logged in users.
Part of MDL-61864
