Allow online acceptance of the contract/memorandum of understanding #3019
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
At the moment, the process for accepting the data sharing and financial agreement is: 1. download a pdf * print it out * get someone to sign it * scan it * email it back to us * we rename the file and save it in Google Drive * we then update the organisation to say the MOU is signed * sometimes we also: * print it out and get it counter-signed * scan it again * email it back to the service Let's not do that any more. When the first service for an organisation that doesn't have the agreement in place is in the process of going live, then they should be able to accept the agreement online as part of the go live flow. This commit adds the pages that let someone do that. Where the checklist shows the agreement as **[not completed]** then they can follow a link where they can download it (as happens now). From here, they should then also be able to provide some info to accept it. The info that we need is: **Version** – because we version the agreements occasionally, we need to know which version they are accepting. It may not be the latest one if they downloaded it a while ago and it took time to be signed off **Who is accepting the agreement** – this will often be someone in the finance team, and not necessarily a team member, so we should let the person either accept as themselves, or on behalf of someone else. If it's on behalf of someone else we need to the name and email address of that person so we have that on record. Obvs if it's them accepting it themselves, we have that already (so we just store their user ID and not their name or email address). We then replay the collected info back in a sort of legally binding kind of way pulling in the organisation name too. The wording we’re using is inspired by what GOV.UK Pay have. Then there’s a big green button they can click to accept the agreement, which stores their user ID and and timestamp.
If the user has selected that they are accepting the agreement on behalf of someone else then we need to make the they provide that person’s details. If they’ve selected that they are accepting the agreement themselves then we have to ignore what they might have put in the ‘on behalf of boxes’ (for example if they filled them out but then changed their mind).
When someone selects that they are accepting the agreement on behalf of someone else then they need to provide that person’s details. Otherwise they shouldn’t care about these extra fields. This commit uses the progressive disclosure pattern from the GOV.UK Frontend Toolkit to hide the additional fields unless someone selects the relevant radio button.
There’s no signature involved any more.
leohemsted
reviewed
Jun 25, 2019
| try: | ||
| float(field.data) | ||
| except (TypeError, ValueError): | ||
| raise ValidationError("Must be a number") |
There was a problem hiding this comment.
i spent a while thinking about this and if we want to bind it more tightly to the pdf version numbers but i can't think of a nice way to do that. i think accepting -inf and NaN and 1e9 is an acceptable quirk.
There was a problem hiding this comment.
I guess far future would be having a platform admin page for uploading new contracts, which would give us a UI for adding version numbers to the database.
| form = AcceptAgreementForm.from_organisation(current_service.organisation) | ||
|
|
||
| if form.validate_on_submit(): | ||
| current_service.organisation.update( |
There was a problem hiding this comment.
do we have a process in place to validate/audit the data? especially in terms of the version number i'm thinking.
do we have a plan to notify ourselves when someone signs an agreement for an organisation?
There was a problem hiding this comment.
Discussed with @yahoopete. We’re happy to keep an eye on the data for bad version numbers or email addresses for the moment.
If we’re not sure whether a user belongs to a crown organisation or not we want to fix that before. This is a last-ditch fallback because we shouldn’t be adding new organisations without also setting their crown status.
Direct users to contact us if crown status unknownIf we’re not sure whether a user belongs to a crown organisation or not we want to fix that first, before we let them sign the agreement. This is a last-ditch fallback because we shouldn’t be adding new organisations without also setting their crown status. Looks like this:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Story: https://www.pivotaltracker.com/story/show/166497058
Content: https://docs.google.com/document/d/1ELqNt15CUW9Laihhl72RcPrfphFlc4xUNhAPuH9FeYA/edit#heading=h.nv75d9tmh567
This shouldn’t be deployed until the latest versions of the agreement have been uploaded into S3.
Before
After