e petitions

Peticiones

Esta es la base de código para el Servicio de Peticiones del Gobierno del Reino Unido y del Parlamento.

Configuración

Recomendamos usar Docker Desktop para configurar rápidamente. Si prefiere no usar Docker, necesitará instalados Ruby (3.2+), Node (20+) y PostgreSQL (16+).

Crea las bases de datos

 docker compose run --rm web rake db:setup

Cargue la lista de países

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

Obtenga la lista de regiones

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

Obtenga la lista de circunscripciones

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

Obtener la lista de departamento

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

Habilitar el conteo de firma

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

Iniciar los servicios

 docker compose up

Una vez que los servicios han comenzado, puede acceder a la parte delantera, la back -end y los correos electrónicos enviados.

Pruebas

Antes de ejecutar cualquier prueba, la base de datos debe estar preparada:

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

Puede ejecutar la suite de prueba completa usando el siguiente comando:

 docker compose run --rm web rake

Las especificaciones individuales se pueden ejecutar usando el siguiente comando:

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

Del mismo modo, las características de pepino individuales se pueden ejecutar utilizando el siguiente comando:

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

Portal de moderación SSO

El portal de moderación se autentica utilizando la gema Omniauth e implementa un envoltorio de luz en torno a estrategias para que se puedan admitir múltiples configuraciones de una estrategia, por ejemplo, dos o más proveedores de identidad SAML.

El config/sso.yml tiene una configuración de la estrategia Developer para el desarrollo local que no debe usarse en la producción. La configuración de prueba en el archivo muestra cómo se configuraría un IDP SAML típico.

Hay cuatro atributos clave que deben devolverse en el hash omniauth auth_info , estos son first_name , last_name , email y groups . El atributo email actúa como el UID para el usuario y el atributo groups controla qué papel es asignado.

Los atributos de configuración son:

• nombre

  Este es un atributo requerido y debe ser único. También debe ser adecuado para su uso en una URL, ya que forma parte de la URL de devolución de llamada para Omniauth.

• estrategia

  Esta es la estrategia Omniauth para usar como clase principal para el proveedor de identidad.

• dominio

  La lista de dominios de correo electrónico para usar con este proveedor de identidad, por ejemplo,

   domains :
    - " example.com "

• roles

  Controla el mapeo de los groups atributos al rol asignado, por ejemplo,

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

  El valor predeterminado para cualquiera de los tres roles es un conjunto vacío, por lo que si un proveedor de identidad solo se usa para uno de los roles, entonces no hay necesidad de configurar a los demás.

• configuración

  Esta es la configuración que se pasa a la estrategia Omniauth y debe ser un hash de las opciones documentadas respaldadas por la estrategia.