User agreement

[Atmire-Kristof]

References

• Fixes User Agreement / Privacy Statement #736
• Depends on Hard redirect after log in #856

Description

This PR adds a User Agreement at /info/end-user-agreement that all registered users have to agree with before being able to do anything else.

This PR also adds the privacy statement page. You can find it at /info/privacy. It isn’t referenced anywhere yet in this PR. That is done by #861, which adds a footer link and mentions it in the cookie popup. That PR also adds a footer link to the end user agreement.

Instructions for Reviewers

Changes made:

• EndUserAgreementService: A service to check or update whether or not a user has accepted the agreement. There's currently two ways an agreement can be accepted:
  • A cookie in the user's browser storing a boolean
  • Logged in e-person's dspace.agreements.end-user metadata
• Two new guards: EndUserAgreementCookieGuard returning true when the cookie is accepted and EndUserAgreementCurrentUserGuard returning true when the user's metadata contains "true" OR no user is logged in (anonymous). In case these guards consider the agreement not accepted, it'll return a UrlTree to a new EndUserAgreementComponent with the original destination as a redirect url in the query parameters.
• EndUserAgreementCookieGuard is configured at route /register/:token. This is so the User Agreement can be accepted during registration.
• EndUserAgreementCurrentUserGuard is configured on most routes (with the exception of /reload, /register, /login, /logout, /info (new) /unauthorized and **)
• EndUserAgreementComponent: A component displaying the User Agreement (currently Lorem Ipsum) with a checkbox at the bottom to accept the agreement. This checkbox is automatically selected when: The cookie contains "true" OR the current user's metadata contains "true". When the checkbox is selected, you're able to click "Save". Clicking "Save" will set the cookie (when anonymous) or metadata (when authenticated) and redirect the user back to their original destination.

How to un-agree during testing:

• You can remove the cookie by using your browser's dev tools.
• You can reset the metadata by saving with an unchecked "agree" checkbox. The save button will be disabled if you uncheck, but you can remove the disabled attribute from the save button in the dev tools, and save anyway to reset the metadata for a user that has already agreed.

Ensure both the cookie and user metadata are not set to "true", before attempting any of these scenarios:

• Visit any route blocked by authentication and login to an authorised account after being redirected to /login. You should be redirected to the User Agreement page. Accepting the User Agreement should set the user's metadata to "true" and redirect you back to your original destination.
• Visit any public page and login using the dropdown at the top. Again, you should be redirected to the User Agreement page and after accepting, redirected back to the public page you were on.
• Register a new user. After clicking the link in your email, the User Agreement should pop up. Accepting it should set the cookie to "true" and redirect you back to /register/:token to continue the registration.

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes TSLint validation using yarn run lint
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• If my PR includes new, third-party dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.

[lgtm-com]

This pull request introduces 1 alert when merging c5e9756 into dd03745 - view on LGTM.com

new alerts:

• 1 for Unused variable, import, function or class

[tdonohue]

👍 @Atmire-Kristof : Code looks good. I did some basic testing of the "User Agreement" today after authenticating.

• Verified clicking Cancel logs you out
• Verified I cannot bypass the User Agreement by trying to jump to a different page in the app
• Verified accepting the user agreement works well (and only possible after I click checkbox)
• Verified the privacy statement text appears a /info/privacy

One question I ran into:

• How do I force users to (re)accept a changed User agreement? For example, if the text of the user agreement requires major updates, I'd expect there should be a way for an Administrator to "reset" all users and force them to agree again.

Overall, I think this code & feature looks good enough as-is, so I'll approve it now. Any improvements could be done in a follow-up PR. I was just unclear how to "reset" the User Agreement acceptance for one user (or all users)...I'm not seeing a way to get that to work.

[artlowel]

@tdonohue:

One question I ran into:

• How do I force users to (re)accept a changed User agreement? For example, if the text of the user agreement requires major updates, I'd expect there should be a way for an Administrator to "reset" all users and force them to agree again.

Overall, I think this code & feature looks good enough as-is, so I'll approve it now. Any improvements could be done in a follow-up PR. I was just unclear how to "reset" the User Agreement acceptance for one user (or all users)...I'm not seeing a way to get that to work.

The only way to do it right now, is using a db query to reset those metadata values for one or more EPersons. Doing it in bulk from the UI would require a dedicated rest endpoint.

Since this is a task that will only be necessary every once in a while, perhaps we can create a script to do this. It could have a param to do it for one, multiple or all EPersons. And that way we don't need to create a custom endpoint or UI to do so.

[LucaGiamminonni]

@artlowel

Since this is a task that will only be necessary every once in a while, perhaps we can create a script to do this. It could have a param to do it for one, multiple or all EPersons. And that way we don't need to create a custom endpoint or UI to do so.

I am currently working on something like this: I thought about creating a script that, given a metadata, deletes all its values. I thought of structuring it in a general way so that maybe it can also be used for other similar purposes. What do you think about it?

[artlowel]

@LucaGiamminonni Sure, that sounds good!

[LucaGiamminonni]

I looked at the code and it looks okay. I have tested the behavior that is expected from the changes in this PR and the main things I have verified are:

• at the login of a user who has never accepted the user agreements, the page with the user agreements to be accepted is shown
• it is not possible to change the page until the conditions are accepted
• since the user accepts the conditions he can browse the application without problem
• the metadata that stores the information that the user agrees to the End User Agreement is saved correctly
• at the next login of the same user, the End User Agreement page is not shown again
• the privacy statement text is shown on the page /info/privacy

[tdonohue]

Just to close up the discussion above. I agree with the analysis of @artlowel and @LucaGiamminonni. To "reset" the user agreement, we could just create a script (ideally one that supports "Scripts & Processes" so that it can be run from either CLI or Admin UI) which updates the database by clearing out the user agreement metadata field. I'll create a new ticket for that work, and schedule it for Beta 5

So, this PR can be merged as is. Thanks @Atmire-Kristof !