Release 488

We currently have a number of new fields that are available in the dev/test CRM environment but not production. In order to be able to deploy the code all the way to production before the attributes are available we need to ignore them from the mapping process.

Adds ability to exclude certain attributes from the mapping process depending on environment.

Excludes magic link attributes from being mapped in production (as they are not yet available).

Release 487

Currently when an enum is returned the integer value is used. This seems to cause an issue with swagger-codegen spitting out invalid Ruby code, for example:

0 = 0.freeze

By serializing enums as string values I'm hoping it fixes the code generator.

We don't use enums in either of the client apps yet, so this change isn't breaking.

Release 485

Trello-776

This PR deals with the third step of migrating existing candidates onto the new privacy policy via a mailing list sign up in the GiT app:

• Refactor existing endpoints to exchange access tokens for candidate data
• Add new magic link token endpoints (creating tokens and exchanging for mailing list candidate data)
• Expire magic link tokens after 48 hours and ensure they are only single-use tokens. Write to field indicating when token is generated/used.
• Add CRM client and restrict access to magic link generation endpoint.
• Add job to process pending magic link generations. Connect models to CRM attributes (need CRM changes in prod first)
• Update the GiT app to handle mailing list sign up via magic links
• Handle scenario where a user clicks on an expired magic link

---

• Set expiry date on magic link tokens

Change the createdAt date to be expiresAt and set to 48 hours in the future when creating a magic link token.

Check that the token is valid before responding with a pre-filled MailingListAddMember model.

If the magic link could not be matched to a candidate (or if it matches to multiple candidates) we return BadRequest with a status of Invalid.

If a token was matched to a candidate but the expiry date has passed we return BadRequest with a status of Expired.

• Prevent multiple use of magic link tokens

Update the MagicLinkTokenStatusId on generating and exchanging tokens.

Check that a token has not already been exchanged and return BadRequest with a status of AlreadyExchanged if it has been used already.

• Encapsulate magic link token exchange into result model

Shifts some of the logic from the controller that determines the state of a magic link token (expired/valid/already exchanged/invalid) into a result model. Change to return Unauthorized instead of BadRequest with an applicable status of Invalid, Expired or AlreadyExchanged.

Release 480

Trello-776

This PR deals with the second step of migrating existing candidates onto the new privacy policy via a mailing list sign up in the GiT app:

• Refactor existing endpoints to exchange access tokens for candidate data
• Add new magic link token endpoints (creating tokens and exchanging for mailing list candidate data)
• Expire magic link tokens after 48 hours and ensure they are only single-use tokens. Write to field indicating when token is generated/used.
• Add CRM client and restrict access to magic link generation endpoint.
• Add job to process pending magic link generations. Connect models to CRM attributes (need CRM changes in prod first)
• Update the GiT app to handle mailing list sign up via magic links
• Handle scenario where a user clicks on an expired magic link

---

• Add magic link token fields to candidate

Add a field to store a magic link token against a candidate and the datetime that the token was created, so that we can enforce token expiry.

Only the token field itself is mapped to the CRM for now; the others will be mapped later on.

So that we can deploy this to production the EntityFieldAttribute has been updated with an Transient option. If set, the BaseModel will not map the fields to/from CRM Entity objects. This means we can safely deploy without the CRM having been updated to include the new field.

• Update CrmService to support magic links

We need to be able to query multiple candidates by their id from the CRM, so that we can bulk-process the magic link token generation (the CRM will be sending emails to thousands of candidates).

In addition, we need to be able to take a magic link from a request and find the corresponding candidate record. This method returns a collection of candidates in the edge case that a magic link has been duplicated during generation or when a contact record has been copied in the CRM. It has a null/empty string guard statement to ensure potentially expensive queries are avoided (most contacts won't have a magic link token set).

• Add magic link token generator service

Add a service to generate secure, random 128 bit magic link tokens. It also has a method that will exchange a valid token for the associated Candidate record.

In the unlikely event that two candidates have been assigned the same magic link token, the service will return null (ultimately forcing a re-generation of the token for that candidate).

• Add endpoint to generate candidate magic link tokens

Introduce a new endpoint that will enable the CRM to batch-generate magic links for candidates.

• Exchange magic link token for a prefilled MailingListAddMember

Adds an endpoint that accepts a valid magic link token and returns a pre-filled MailingListAddMember model.

Release 483

These access token endpoints have been replaced with new endpoints in the format /path/to/resource/exchange_access_token/{accessToken}. The API clients have been updated so they can safely be removed.

Release 482

Bumps actions/cache from v2 to v2.1.4.

Release notes

Sourced from actions/cache's releases.

v2.1.4

• Make caching more verbose #650
• Use GNU tar on macOS if available #701

Commits

• 26968a0 Make save/restore logs akin (#509)
• aeaf731 Use @actions/cache version 1.0.6 (#525)
• 56a8a2f Merge pull request #514 from eregon/recommend-setup-ruby-bundler-cache
• 1bfe3ac Recommend ruby/setup-ruby's bundler-cache: true option
• 3543324 Merge pull request #434 from DanielHabenicht/patch-1
• 3303695 Merge pull request #507 from odin-delrio/patch-1
• e64ab30 Improved gradle cache key calculation example
• 26c48dc Merge pull request #506 from actions/cache-matrix-example
• 72f66cf Added a cache example when using matrix
• 9f3a4d3 Merge pull request #443 from guilleijo/pipenv-example
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Release 478

The two API clients now use the new authentication method and the legacy SHARED_SECRET environment variable is no longer used. This commit removes the associated authentication code.

Release 468

Add instructions for setting up a new service that integrates with the API.

Release 481

The Production delivery step does nothing but add confusion

Additionally remove the CVE.yml file so CVE checks are not being carried out. The logic behind this is they are failing and we intend on finding a better way to fix them automatically. so this reduces noise

Release 479

Trello-776

This PR deals with the first step of migrating existing candidates onto the new privacy policy via a mailing list sign up in the GiT app:

• Refactor existing endpoints to exchange access tokens for candidate data
• Add new magic link token endpoints (creating tokens and exchanging for mailing list candidate data)
• Expire magic link tokens after 48 hours and ensure they are only single-use tokens. Write to field indicating when token is required/set.
• Add an API client for the CRM with access to the magic link generation endpoint
• Update the GiT app to handle mailing list sign up via magic links
• Handle scenario where a user clicks on an expired magic link

---

We currently only have one way of the API clients obtaining candidate data, which is by exchanging a user-generated access token for a resource (pre-filled mailing list/tta/event sign up):

POST /path/to/resource/{accessToken}

Going forward we are also going to support 'magic links' as a way of authenticating users. To that end, the endpoints are being refactored so we will ultimately be left with:

POST /path/to/resource/exchange_access_token/{accessToken}
POST /path/to/resource/exchange_magic_link_token/{magicLinkToken}

This PR adds in the /path/to/resource/exchange_access_token/{accessToken} endpoint and leaves the current endpoint in for backwards-compatibility. Once this is merged down the clients can be updated and the original endpoint removed.