Deploy swh-web-alter

Related issue: https://gitlab.softwareheritage.org/product-management/swh-archive-website/-/issues/1

swh-web-alter has been released in swh-web@v0.9.7. To activate this new django app in the swh-web project we'll need:

An SMTP server

swh-web-alter sends:

• email notifications to operators (us) when a request is created or when a requester sends a message to the support role
• email notifications to requesters when an operator mentions a requester
• magic auth link to users when they want to access their request

The volume will depends on the numbers of alteration requests. rate limits are in place in the views and should avoid abuses related to mail sending.

Email aliases

[!note] the list of people behind these aliases is still TBD (in gitlab 17.10 this will be a nice alert)

In a keycloak context we need 4 email aliases to send notifications to the 4 different roles groups in the app:

• support: the operators in charge of handling new alteration requests, will receive notifications when new messages are posted or new requests added
• manager: who to call when a request needs an escalation
• legal: inria's dpo
• technical: swh ops in charge of handling/applying alteration requests

Admin permission

To access the swh-web-alter admin interface, users need to have the (new) swh.web.admin.alter role in Keycloak.

Configuration

In the swh config file / var:

1. add swh.web.alter to swh_extra_django_apps, this acts as a feature flag
2. email_setup: a new dict containing settings to be able to send emails from swh-web:
   • backend: "django.core.mail.backends.smtp.EmailBackend"
   • host: "smtp host name",
   • port: smtp port number,
   • username: "smtp username",
   • password: "smtp password",
   • use_tls: True or False,
   • use_ssl: True or False,
   • default_from_email: "no-reply@softwareheritage.org",
3. alter_settings: a new dict containing settings for swh-web-alter itself:
   • support_mail_alias: the address created for the support alias
   • manager_mail_alias: ... manager alias
   • legal_mail_alias: ... legal alias
   • technical_mail_alias: ... technical alias
   • block_disposable_email_domains: False (if enabled it will block new alteration requests when a user uses a known throwaway mail service)

DB Migrations

swh.web.alter contains new db models, once the app is activated manage.py migrate will apply /swh/web/alter/migrations/0001_initial.py

Once again the volume of data will depends on the numbers of alteration requests and purging mechanisms will be added at some point.

python requirements

swh-web-alter depends on disposable-email-domains and django-bootstrap5 as defined in requirements.txt.

Not needed

• No queue management
• ...

How to check that everything went well ?

swh.web.alter is in the list of django apps:

• a link to "Content policy" appears in the footer for all users
• a link to "Alteration requests" appears in the sidebar for admins

requirements are installed:

• the forms are looking bootstrap-ish

Emails are properly setup:

• after creating a new alteration request an email is sent to the requester's email address and to the support email alias

changed milestone to %Tooling for takedown notices [Roadmap - Collect]

changed the description

In a keycloak context we need 4 email aliases to send notifications to the 4 different roles in the app:

• support: the ones in charge of handling new alteration requests, will receive notifications when new messages are posted or new requests added
• manager: who to call when a request needs an escalation
• legal: inria's dpo
• technical: swh ops in charge of handling/applying alteration requests

I believe that this conflates two separate setups:

• webapp user permissions (which, in staging and production, are set up as roles in keycloak and mapped to user permissions in django)
• email aliases (which are completely unrelated to keycloak, and set up on gandi)

Looking at settings, it seems that you need email aliases used as recipients for notifications for the 4 different roles, but only one "alter admin" role on keycloak. Is that correct?

webapp user permissions (which, in staging and production, are set up as roles in keycloak and mapped to user permissions in django)

I completely forgot about this requirement, thank you for raising this point. I've updated the ticket to reflect this.

email aliases (which are completely unrelated to keycloak, and set up in django)

Looking at settings, it seems that you need email aliases used as recipients for notifications for the 4 different roles, but only one "alter admin" role on keycloak. Is that correct?

yes, and the list of team members with the swh.web.admin.alter role in keycloak is still TBD

I wrote "email aliases are set up in django" but my neurons got crossed, this should have read "email aliases are set up on gandi" (which is a whole other bag of fish)

If it's any consolation, I understood what you meant.

changed the description

assigned to @guillaume