e petitions

Pétitions

Il s'agit de la base de code pour le gouvernement britannique et le service des pétitions du Parlement.

Installation

Nous vous recommandons d'utiliser Docker Desktop pour obtenir une configuration rapidement. Si vous préférez ne pas utiliser Docker, vous aurez besoin de Ruby (3.2+), Node (20+) et PostgreSQL (16+) installés.

Créer les bases de données

 docker compose run --rm web rake db:setup

Chargez la liste des pays

 docker compose run --rm web rake epets:countries:load

Retrouver la liste des régions

 docker compose run --rm web rails runner 'FetchRegionsJob.perform_now'

Répondre à la liste des circonscriptions

 docker compose run --rm web rails runner 'FetchConstituenciesJob.perform_now'

Retrouver la liste des départements

 docker compose run --rm web rails runner 'FetchDepartmentsJob.perform_now'

Activer le comptage des signatures

 docker compose run --rm web rails runner 'Site.enable_signature_counts!(interval: 10)'

Démarrer les services

 docker compose up

Une fois que les services ont commencé, vous pouvez accéder au frontal, à l'arrière et à tous les e-mails envoyés.

Tests

Avant d'exécuter les tests, la base de données doit être préparée:

 docker compose run --rm web rake db:test:prepare

Vous pouvez exécuter la suite de test complète à l'aide de la commande suivante:

 docker compose run --rm web rake

Les spécifications individuelles peuvent être exécutées en utilisant la commande suivante:

 docker compose run --rm web rspec spec/models/parliament_spec.rb

De même, les fonctionnalités de concombre individuelles peuvent être exécutées en utilisant la commande suivante:

 docker compose run --rm web cucumber features/suzie_views_a_petition.feature

Portail de modération SSO

Le portail de modération est authentifié à l'aide de la gemme Omnioth et implémente un emballage léger autour des stratégies afin que plusieurs configurations d'une stratégie puissent être prises en charge, par exemple deux ou plusieurs fournisseurs d'identité SAML.

Le config/sso.yml a une configuration de la stratégie Developer pour le développement local qui ne doit pas être utilisée dans la production. La configuration de test dans le fichier montre comment un IDP SAML typique serait configuré.

Il y a quatre attributs clés qui doivent être renvoyés dans le hachage Omniauth auth_info , ceux-ci étant first_name , last_name , email et groups . L'attribut email agit comme l'UID pour l'utilisateur et l'attribut groups contrôle le rôle qu'ils sont attribués.

Les attributs de configuration sont:

• nom

  Il s'agit d'un attribut requis et doit être unique. Il doit également être adapté à une utilisation dans une URL car il fait partie de l'URL de rappel pour Omniauth.

• stratégie

  Il s'agit de la stratégie Omniauth à utiliser comme classe parent pour le fournisseur d'identité.

• domaines

  La liste des domaines de messagerie à utiliser avec ce fournisseur d'identité, par exemple

   domains :
    - " example.com "

• rôles

  Contrôle la cartographie des groups attribut au rôle assigné, par exemple

   roles :
    sysadmin :
      - " System Administrators "
    moderator :
      - " Petition Moderators "
    reviewer :
      - " Petition Reviewers "

  La valeur par défaut de l'un des trois rôles est un ensemble vide, donc si un fournisseur d'identité n'est utilisé que pour l'un des rôles, il n'est pas nécessaire de configurer les autres.

• configurer

  Il s'agit de la configuration qui est transmise à la stratégie Omniauth et devrait être un hachage des options documentées prises en charge par la stratégie.