Features examples

dynamic-modal.md

I would like to allow a controller to define the size of the modal dynamically.

Currently, the modal is defined in app/views/shared/_modal.html.erb There is a turbo-frame tag with the id main-modal-content for the general modal.

An example of a response that the server can make: app/views/instruction/refuse_authorization_requests/new.html.erb

Note that there is the same main-modal-content turbo-frame.

A stimulus controller attached to the modal would need to be created that can “listen” to the server's responses and apply the size defined in the view.

If nothing is defined, apply the default size, which is currently fr-col-12 fr-col-md-8 fr-col-lg-6.

I would like everything to happen in the view's DOM and nothing on the server side.

proconnect-connexion.md

Abstract

This application allows 2 identity federator for authentication:

1. ProConnect
2. MonComptePro

We're going to use the ProConnect federator for authentication by default (currently it is the MonComptePro federator used, you have to visit a special path to connect with ProConnect federator).

MonComptePro always deliver a validated siret for the current user, it is no longer the case for ProConnect: it depends of the identity provider uid.

There is 3 cases:

1. The identity provider uid delivers a validated siret, and the user can choose an organization before the connexion on this application : the user is authenticated with a validated siret and redirect to the dashboard ;
2. The identity provider uid does not deliver a validated siret but we have a finite list of sirets associated to this uid: the user is authenticated and there is a choice to select an organization to use from this list, combined with the list of organizations already linked to the user (if any exists) ;
3. The identity provider uid does not deliver a validated siret and we have no finite list of sirets associated to this uid: the user is authenticated and can choose on a list of organizations to use if there is already a link between this user and another organization, and can add a siret to join this organization.

On the case 3., if user choose to add a siret, we mark this linked as "verified" false.

The case 1. only exists with provider uid 71144ab3-ee1a-4401-b7b3-79b44f7daeeb which is MonComptePro uid.

For this feature, we're going to implement cases 1. and 3. only.

Implementation

Model

We need to add a new field verified to the OrganizationsUser model, default to true.

The User::IDENTITY_PROVIDERS constant have to be updated to include the verified value as a value. Here is an example of the new constant:

IDENTITY_PROVIDERS = {
  '71144ab3-ee1a-4401-b7b3-79b44f7daeeb' => {
    name: 'MonComptePro',
    choose_organization: false,
    verified: true
  },
  'e2f397e0-f2a5-4cbb-b19f-8b3b54410c26' => {
    name: 'Agents de l'Administration Centrale des ministères économiques et
    financiers (Réseau Interministériel de l'État)',
    choose_organization: true,
    verified: false
  }
}

By default, if there is no uuid in the constant, the verified value is false, and choose_organization is true.

Organizers / interactors / controllers

AuthenticateUserThroughProConnect organizer will be updated to handle the new paradigm. It should affects to context a verified_organization field as a boolean. The SessionsController should handle this field to redirect to the right path.

If it is true, the user is redirected to the dashboard, if it is false, it should be redirected to the organization selection page.

Organization selection page

You should introduce a new page to select an organization. Controllers name should be OrganizationsController and the action should be index, new, create, and a controller JoinOrganizationController#create. Screenshots are available within claude/proconnect-connexion/ folder.

On the create action, we should create a new Organization, and the form should call the JoinOrganizationController#create action.

Features tests

You should add tests to cover the new feature, use the uuid from the example to implement the case 1. and 3. described above. You should iterate on steps to mock the ProConnect federator.

request-changes-templates.md

I would like to add the option for instructors to create templates for change requests or rejections, in order to save time when reviewing requests.

These templates will be limited to three per pair of authorization type and template type (rejection or change request).

Each template will be able to interpolate the following variables:

• request_url, the link to the request
• request_title, the title of the request
• request_id, the request ID

The syntax %{variable} will be used for variables. If a variable is not found, the template cannot be saved.

Note that the template will not handle the header or footer, which are fixed.

There will be an administration interface to manage these templates, reserved for administrators of the authorization type. This will be a table where you can edit/delete/add a template.

In the edit view, there will be instructions explaining how to insert variables and the available variables, as well as a preview that will include the variables with example values, as well as the default header and footer . The template will have a short title (<= 50 characters), with no size limit on the content. You will be able to choose whether it is a rejection or modification request template.

In the request instruction view, you will be able to choose a template. When you click on the template, the content of the message will be replaced by the content of the template.

More details within the following ticket: LINK