feat: add configuration, custom Auth and event handlers for Diamond Light Source

[GrantDLS]

Description

This PR is to add the necessary configuration files, custom authorization class and email event handler for Diamond Light Source to be able to use User Office Project.

Motivation and Context

• apps/backend/src/auth/DlsUserAuthorization.ts
  • Our own custom authorization class that works the same as the OAuthAuthorization class that it extends, except for it excludes some user attributes being pulled from the OAuth provider.
• apps/backend/src/config/dls/configureDLSEnvironment.ts
  • This previously contained a helper method getUASInstance() which read the value of a .env variable, but this change has been removed after feedback from the collaboration.
• apps/backend/src/config/dependencyConfigDLS.ts
  • This is standard and just sets the dependency mappings
• apps/backend/src/eventHandlers/email/DLS/DLSEmailHandler.ts
  • This is our email handler in which we're currently handling the following 2 events: PROPOSAL_SUBMITTED and PROPOSAL_CO_PROPOSER_INVITES_UPDATED. The logic for building and sending each email type is separated into different files for readability.
• apps/frontend/public/images/diamond-white.svg
  • This is our logo for use in the header.

How Has This Been Tested

A test has been written for the email handler to ensure the correct email template is used for each event that we're handling.

Changes

There are only 2 changes to the core files of the code base:

• apps/backend/src/auth/OAuthAuthorization.ts
  • This class mostly meets our needs, but a small change is needed in externalTokenLogin(). I've extended the class, but needed access to the private method getUserRole(), so I've made it's access modifier protected rather than private.
• apps/backend/src/config/index.ts
  • A case has been added to the switch statement to load the DLS config file when it is set in the .env file.

Tests included/Docs Updated?

N/A

[yoganandaness]

@GrantDLS Is this PR ready to be reviewed? If so, could you add the label "review:please"

[GrantDLS]

@GrantDLS Is this PR ready to be reviewed? If so, could you add the label "review:please"

I've done quite a bit of refactoring since I created the PR. Just adding a couple of tests for the email handler and I'll add the label. Thank you, @yoganandaness .

[zacharyjhankin]

Can you add an image of the email PROPOSAL_CO_PROPOSER_INVITES_UPDATED?

[yoganandaness]

Other the new env, all other looks good.

[joeshannon]

Other the new env, all other looks good.

Thanks for taking a look.

By new env, do you mean that the new DLS environment needs some additional config?

[yoganandaness]

Other the new env, all other looks good.

Thanks for taking a look.

By new env, do you mean that the new DLS environment needs some additional config?

Is it possible to avoid this env(UAS_INSTANCE) and instead of that, set the settings values directly in the dashboard?

[joeshannon]

Is it possible to avoid this env(UAS_INSTANCE) and instead of that, set the settings values directly in the dashboard?

We could do, the idea with this was that this would point to different systems depending on the environment e.g. prod/staging but I suppose it could be set in the app.

Looking at it now we could probably adapt to use the existing env var that STFC have process.env.PROFILE_PAGE_LINK to derive it.

Do any facilities add custom settings to the settings table or should it be kept to those in the SettingsId enum?

[yoganandaness]

process.env.PROFILE_PAGE_LINK

@joeshannon

Agree with you over the process.env.PROFILE_PAGE_LINK

Usually, SettingsId enum and settings table are in sync

[yoganandaness]

@zacharyjhankin Just wanted to add in here that since this has length commits, i would recommend to do a Squash and Merge, so the master and develop branch holds only one commit sha.

[GrantDLS]

Other the new env, all other looks good.

Thanks for taking a look.
By new env, do you mean that the new DLS environment needs some additional config?

Is it possible to avoid this env(UAS_INSTANCE) and instead of that, set the settings values directly in the dashboard?

Thanks for taking a look at this @yoganandaness . The reason we went with an environment variable over a settings value is because it's for something that's specific to Diamond. Having it as an environment variable means we can use it without polluting the SettingsId enum with things that are institution specific.

Further to this, it's not something we'd want a user to be able to change in the UI. We want it set at deployment only.

EDIT: I should also add, that the environment variable isn't required to be set by other institutions, since it's only used by the helper function defined in our configuration setup file.

[yoganandaness]

Other the new env, all other looks good.

Thanks for taking a look.
By new env, do you mean that the new DLS environment needs some additional config?

Is it possible to avoid this env(UAS_INSTANCE) and instead of that, set the settings values directly in the dashboard?

Thanks for taking a look at this @yoganandaness . The reason we went with an environment variable over a settings value is because it's for something that's specific to Diamond. Having it as an environment variable means we can use it without polluting the SettingsId enum with things that are institution specific.

Further to this, it's not something we'd want a user to be able to change in the UI. We want it set at deployment only.

EDIT: I should also add, that the environment variable isn't required to be set by other institutions, since it's only used by the helper function defined in our configuration setup file.

If I understand your use case correctly, you don't want the user to set this value in the dashboard and want to get the value directly from env during the deployment. However, if you can see the settings page, PROFILE_PAGE_LINK is a part of the settings enum, it becomes automatically available to the User Officer to edit this value immaterial of if it comes from env or hardcoded. Correct me if I'm wrong.

However, if you feel that you would like to set it during run time, we can make this env applicable to all the facilities as well. Could you rename the env (UAS_INSTANCE ) to PROFILE_PAGE_LINK, so that it aligned with the settings value.

[GrantDLS]

Sorry, @yoganandaness I don't think I quite understand. I'll explain our use case some more.

The environment variable is only used in one place, for the following function inside configureDLSEnvironment.ts. This function is currently just used once when sending out an invite to join a proposal (since we currently want users to sign up via UAS).

function getUASInstance() {
  let instance = process.env.UAS_INSTANCE || 'https://uas.diamond.ac.uk/uas';
  if (instance.endsWith('/')) {
    instance = instance.slice(0, -1);
  }

  return instance;
}

I can see a couple of issues with using the PROFILE_PAGE_LINK variable. Firstly, I'd have to use a regex to extract just the domain - not a huge issue but seems unnecessary. Secondly, there might be a rare case where we want the UAS_INSTANCE and the PROFILE_PAGE_LINK to point to different domains.

Unless I'm missing something with how the application interprets environment variables, the way we've done it currently seems like the most straightforward and unobtrusive way. It doesn't affect any of the other collaborators instances or require any changes.

[zacharyjhankin]

From the diamond side right now, we do not want UAS_INSTANCE to be configurable at run time, so do not want to use PROFILE_PAGE_LINK. So we hope to add UAS_INSTANCE as a environment variable as the PR currently stands.

[yoganandaness]

@zacharyjhankin As we discussed over the call, we recommend trying with the existing env variable PROFILE_PAGE_LINK. Let us know, if you have any issues.

Thanks

[GrantDLS]

Thank you for taking the time to have a call with us this morning @yoganandaness

We've decided to just hard code our UAS domain for now. This removes the need for the environment variable and the helper.

[yoganandaness]

Is it possible to avoid this env and instead of that, set the settings values directly in the dashboard?

[zacharyjhankin]

lgtm