e petitions

Petitionen

Dies ist die Code -Basis für die britische Regierung und das Parlament des Parlaments.

Aufstellen

Wir empfehlen, Docker Desktop zu verwenden, um schnell eingerichtet zu werden. Wenn Sie es vorziehen möchten, Docker nicht zu verwenden, benötigen Sie Ruby (3.2+), Knoten (20+) und PostgreSQL (16+) installiert.

Erstellen Sie die Datenbanken

 docker compose run --rm web rake db:setup

Laden Sie die Länderliste

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

Abrufen Sie die Liste der Regionen ab

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

Rufen Sie die Liste der Wahlkreise ab

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

Abrufen Sie die Abteilungsliste ab

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

Aktivieren Sie die Signaturzählung

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

Starten Sie die Dienste

 docker compose up

Sobald die Dienste begonnen haben, können Sie auf das Front -End, das Back End und alle gesendeten E -Mails zugreifen.

Tests

Vor dem Ausführen von Tests muss die Datenbank vorbereitet werden:

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

Sie können die vollständige Testsuite mit dem folgenden Befehl ausführen:

 docker compose run --rm web rake

Einzelne Spezifikationen können mit dem folgenden Befehl ausgeführt werden:

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

In ähnlicher Weise können einzelne Gurkenfunktionen mit dem folgenden Befehl ausgeführt werden:

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

Moderationsportal SSO

Das Moderationsportal wird mit dem Omniauth -Edelstein authentifiziert und implementiert eine Lichtverpackung um Strategien, sodass mehrere Konfigurationen einer Strategie unterstützt werden können, z. B. zwei oder mehr SAML -Identitätsanbieter.

Die config/sso.yml verfügt über eine Konfiguration der Developer für die lokale Entwicklung, die nicht in der Produktion verwendet werden sollte. Die Testkonfiguration in der Datei zeigt, wie ein typisches SAML -IDP konfiguriert wird.

Es gibt vier wichtige Attribute, die im Omniauth auth_info Hash zurückgegeben werden müssen, wobei diese first_name , last_name , email und groups sind. Das email -Attribut fungiert als UID für den Benutzer und das Attribut groups steuert, welche Rolle sie zugewiesen werden.

Die Konfigurationsattribute sind:

• Name

  Dies ist ein erforderliches Attribut und muss einzigartig sein. Es muss auch für die Verwendung in einer URL geeignet sein, da es Teil der Callback -URL für Omniauth ist.

• Strategie

  Dies ist die Omniauth -Strategie, die als übergeordnete Klasse für den Identitätsanbieter verwendet werden kann.

• Domänen

  Die Liste der E -Mail -Domänen, die mit diesem Identitätsanbieter verwendet werden sollen, z. B.

   domains :
    - " example.com "

• Rollen

  Steuert die Zuordnung des groups auf die zugewiesene Rolle z. B. die zugewiesene Rolle, z. B.

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

  Die Standardeinstellung für eine der drei Rollen ist ein leerer Satz. Wenn ein Identitätsanbieter nur für eine der Rollen verwendet wird, müssen die anderen nicht konfiguriert werden.

• Konfiguration

  Dies ist die Konfiguration, die an die Omniauth -Strategie übergeben wird und ein Hash der dokumentierten Optionen sein sollte, die von der Strategie unterstützt werden.