Giter Site home page Giter Site logo

hitobito / hitobito_sww Goto Github PK

View Code? Open in Web Editor NEW
3.0 3.0 0.0 1.19 MB

A hitobito wagon defining the organization hierarchy and additional features for Schweizer Wanderwege

License: GNU Affero General Public License v3.0

Ruby 94.99% SCSS 2.34% Haml 2.66%

hitobito_sww's Introduction

hitobito logo

Welcome to Hitobito 人人

Hitobito is an open source web application to manage organisation and communities with complex group hierarchies with members, events, courses, mailings, communication and a lot more.

Maintenance Documentation Status GitHub Open Source Helpers Rails Lint and Test

User Guide

A generic user guide in German is available.

Development

Check out our development kit

More detailed development documentation can be found in doc/development.

This is where you also find some Deployment Instructions.

More information about interfaces, api, oauth and oidc is also avaible.

Architecture

The architecture documentation in German can be found in doc/architecture.

Two topics shall be mentioned here explicitly:

Group Hierarchy

Hitobito provides a powerful meta-model to describe group structures. Groups are always of a specific type and are arranged in a tree. Each group type may have several different role types.

This core part of Hitobito does not provide any specific group or role types. They have to be defined in a separate plugin, specific to your organization structure.

An example group type definition might look like this:

class Group::Layer < Group
  self.layer = true

  children Group::Layer, Group::Board, Group::Basic

  class Role < Leader
    self.permissions = [:layer_full, :contact_data]
  end


  class Member < Role
    self.permissions = [:group_read]
  end

  roles Leader, Member
end

A group type always inherits from the class Group. It may be a layer, which defines a set of groups that are in a common permission range. All subgroups of a layer group belong to this range unless a subgroup is a layer itself.

Then all possible child types of the group are listed. When creating subgroups, only these types will be allowed. As shown, types may be organized recursively.

For the ease of maintainability, role types may be defined directly in the group type. Each role type has a set of permissions. They are general indications of what and where. All specific abilities of a user are derived from the role permissions she has in her different groups.

See Gruppen- und Rollentypen for more details and hitobito_generic for a complete example group structure.

Plugin architecture

Hitobito is built on the plugin framework Wagons. With Wagons, arbitrary features and extensions may be created for Hitobito. As mentioned above, as there are no group types coming from Hitobito itself, at least one wagon is required to define group types in order to use Hitobito.

See Wagon Guidelines or Wagons for more information on wagons and its available rake tasks.

Contributing

You are invited to contribute new features, fixes, or updates, large or small; we are always thrilled to receive pull requests, and do our best to process them as fast as we can. Before opening any pull request or issue, please search for existing issues (open and closed) and read the contributing guidelines. If you are part of an organisation that uses Hitobito, please discuss your intent with the responsible person of your organisation.

Community

Hitobito made with 💙 and the incredible community:

  • Jungwacht Blauring Schweiz
  • Puzzle ITC GmbH
  • Pfadibewegung Schweiz
  • Hitobito AG
  • CEVI Regionalverband ZH-SH-GL / CEVI Schweiz
  • Pro Natura Jugend
  • Dachverband Schweizer Jugendparlamente DSJ
  • Insieme Schweiz
  • Forschungstelle Digitale Nachhaltigkeit
  • CH Open
  • Digital Impact Network
  • Schweizer Blasmusikverband
  • Grünliberale Partei Schweiz
  • Die Mitte
  • Stiftung für junge Auslandschweizer
  • Swiss Canoe
  • Schweizerischer Sportverband öffentlicher Verkehr (SVSE)
  • Schweizer Wanderwege

Please contact Hitobito if you want to be part of our community.

License

Hitobito is released under the GNU Affero General Public License.

The Hitobito logo is a registered trademark of Hitobito LTD, Switzerland.


btw: Hitobito 人人 means "everyone"

hitobito_sww's People

Contributors

carlobeltrame avatar daniel-illi avatar kronn avatar mtnstar avatar olibrian avatar thewalkingleek avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

hitobito_sww's Issues

FINANCE: Links im Buchungsbeleg

Als Kassier
möchte ich aus dem Buchungsbeleg direkt die entsprechenden Rechnungen ansehen
um eine umfangreiche Suche zu umgehen.

Aufbauend auf #39 soll direkt pro Rechnungsartikel ein Link auf die entsprechende Rechungen erstellt werden. So kann einfach nachvollzogen werden, welche Rechnungen zu den entsprechenden Buchungen geführt haben.

Tech-Spec

  • Schnelle Navigation von Buchungsbeleg zu gefilterter Rechnungsliste
  • Es werden nur die Rechnungen des Layers betrachtet
  • Umsetzung im Core
  • Baut auf hitobito/hitobito#1799 auf
  • Link nur bei Rechnungsartikeln einfügen, nicht bei berechneten Spalte wie Teilzahlung und Spenden

ToDo

  • Model/View/Controller anpassen
    • Liste der Rechnungen, die einen bestimmten Rechnungsartikel verwenden, auf Model-Ebene bekommen
    • Liste darstellen, eventuell in einem neuen Controller
    • Views anlegen, sofern dry_crud nicht ausreicht
  • Specs schreiben
  • Kunde wegen Übersetzungen informieren
  • Mit angemessener Rolle "durchklicken"
  • CHANGELOG-Eintrag unter "unreleased" unten hinzufügen

INVOICES: Mitgliederausweise sollen auch bei Rechnungen gedruckt werden können

Analog wie bei den Rechnungsbriefen/Briefen soll auch auf der Rechnung die Option zum Drucken des Mitgliederausweises zur Verfügung stehen.

image

Ist die Option 'Mitgliederausweis mit drucken' angewählt, wird der Mitgliederausweis oben rechts gedruckt.

Siehe auch #27 und #52

ToDo

  • Neue Attribute auf Invoice Model
    • :membership_card, :boolean, default: false, null: false
    • :membership_expires_on, :date
  • Rechnungs Formular mit den beiden Attributen ergänzen
  • PDF layout anpassen und wenn Mitgliederausweis drucken diesen entsprechend ausgeben

Tech-Spec

Grundpaket: Anpassungen am Design

  • Farbschema
  • Logo
  • Schriftart
  • Favicon
  • #20

CD/CI-Vorgaben: Nextcloud/swe/projects/SWWA_SchweizerWanderwege/Hitobito/1_Dokumentation/General/00_Grundlagen/CI-CD

EXPORT: Erweitern von Export "Alle Angaben"

Als Benutzer
möchte ich weitere Angaben von Personen exportieren können,
um eine vollständige Liste zu erhalten

Neu soll im csv und excel Export folgende Felder vorhanden sein:

  • Mitgliedernummer
  • Abonummer
  • Berechnetes Feld "Anrede" -> entweder Herr oder Frau oder "leer", abhängig vom Geschlecht.

Mockup

hier folgt ein Mockup ...

Tech-Spec

Umsetzung im SWW Wagon

  • sinngebende Zielrichtung
  • besondere/bekannte Bedingungen und Grenzfälle
  • technische Einschränkungen
  • Ein- und Ausgabeformate beschreiben
  • Umsetzungsplan ergänzen oder anpassen

ToDo

  • Migration erstellen
  • Domainklasse erstellen oder anpassen
  • Model/View/Controller anpassen
  • Specs schreiben
  • Kunde wegen Übersetzungen informieren
  • Mit angemessener Rolle "durchklicken"
  • CHANGELOG-Eintrag unter "unreleased" unten hinzufügen

PEOPLE: Datenabgleich Adress-Informationen DONMAN -> Hitobito

Umsetzung möglichst im Core. Für Umsetzung Ticket nach Core verschieben.

Hitobito besitzt heute ein API auf das nur lesend zugegriffen werden kann. Eine ensprechende Dokumentation befindet sich hier.

Für das Update von Personendaten soll das das neue JSON API sowie Unterstützung für Schreiboperationen implementiert werden. Neben Personendaten sollen auch Telefonnummern (phone_numbers), Social Accounts (social_accounts) sowie Weitere Emails (additional_emails) aktualisiert werden können. (nested/relationships)

Ein Update Request im JSON API Standard für eine Person könnte etwa so aussehen:

POST /api/people/42

{"data": 
  { "attributes": 
    "last_name":"Franz",
"first_name":"Maiyer",
"address": ...
"type":"people"},"relationships":{"phone_numbers":{"data":{"type":"phone_numbers","id":"198"}}},"type":"phone_numbers"}}

Personen Updates via API und Service Tokens sollen im Log der geänderten Person ersichtlich und nachvollziehbar sein. (Paper Trail)

Offene Punkte:

  • Kann DONMAN Personen erstellen?
    • Nein, alle Einträge werden erst in Hitobito erstellt
  • Kann DONMAN Personen löschen?
    • Nein, komplettes Löschen kommt selten vor und erfolgt manuell in allen Systemen

Umsetzung:

  • Umsetzung Feature via hitobito/hitobito#1920
  • Integration/Test mit DONMAN/KB Integrationsumgebung
  • Einführung in Produktionsumgebung

INVOICE: Anpassungen Rechnungen 2

Anpassungen an den Rechnungen

  • Rechnungssteller nicht anzeigen
  • Rechnungsdatum: Unterhalb der Tabelle anzeigen
  • Fällig bis: Unterhalb der Tabelle anzeigen
  • Rechnungsnummer anstelle Rechnungsartikel im Header der Tabelle
  • Absenderadresse nicht darstellen (kommt vom Briefpapier)
  • Rechnungsdatum an der Stelle von Rechnungssteller

Umsetzung im Wagon SWW

Mockup

Image

Todo

INVOICE: Textvorlage für Rechnungen

Prüfen: Macht es evtl. Sinn das wir anstatt Rechnungstextvorlagen gleich Rechnungsvorlagen einführen?
Damit könnte man das gleiche Model Invoice benutzen mit Flag template.
diese Option prüfen und ggf. ein neues Ticket erstellen.

Als Rechnungssteller,
möchte ich beim erstellen von Rechnungen immer wieder auf Textvorlagen zurückgreifen,
um effizient wiederkehrende Rechnungen erstellen zu können.

Unter den Einstellungen kann entsprechende Vorlage erfasst werden. Es können beliebige beliebige Textvorlagen erfasst werden.
Beim Erstellen der Rechnung können die Textvorlagen entsprechend ausgewählt werden und weiter bearbeitet werden.

Mockup

Mögliche Umsetzung unter den Rechnungseinstellungen:

image

-> Name vom Tab neu "Textvorlage"

Tech-Spec

  • Vorlage, um schneller gleichlautende Rechnungen erstellen zu können
  • Wenn Vorlagen existieren, dann wird ein Dropdown mit den Vorlagen angeboten.
  • Vorlagentext wird per JS eingefügt, ersetzt den aktuellen Rechnungstext und kann danach weiter in der Rechung bearbeitet werden.
  • Es können meherer Vorlagen erstellt werden, ähnlich wie bei Anmeldenangaben oder weiteren Telefonnummern.
  • Vorerst soll es mit 5 Vorlagen gut funktionieren

ToDo

  • Migration erstellen
    • neue Tabelle message_templates
    • references :layer
    • varchar :title, null: false
    • text :body
  • Models/Views/Controller anpassen
    • Models
      • MessageTemplate < ActiveRecord::Base
      • InvoiceConfig.has_many :message_templates
    • Rechnungseinstellungen (Controller, View)
    • neuen Brief erstellen (View)
      • Wenn mehr als 1 Vorlage im Layer vorhanden, Dropdown anzeigen
      • Auswahl überschreibt aktuellen Rechnungstext
      • Ob das Template per AJAX geholt wird oder alle vorhandenen direkt im DOM vorhanden sind, ist offen.
        • testen ob 5 - 10 Templates immer noch in vernüftiger Zeit laden
        • wenn zu langsam, dann eher per AJAX holen (Controller, View)
  • Specs schreiben
  • Kunde wegen Übersetzungen informieren
  • Mit angemessener Rolle "durchklicken"
    • in Firefox testen
    • in Chromium-basiertem Browser testen
  • Dokumentation hinzufügen
  • CHANGELOG-Eintrag hinzufügen

PEOPLE: Zugriff auf Rechnungen für Support

Personen mit der Rolle Support sehen heute die Rechnungen der FOs nicht sondern nur die Rechnungen des Dachverbands. Diese Rolle hat die Berechtigung [:layer_and_below_full, :admin, :finance, :impersonation]

Info: Issue enthielt ursprünglich auch noch einen Teil zum anpassen von Abos. Dies wird nun im Issue #94 gelöst.

TechSpec

  • Umsetzung im Wagon
  • Support Personen sollen auch die Rechnungen der FOs sehen und verwalten können.

ToDo

  • neue Ability :complete_finance einführen, die keine Layerbeschränkung hat
  • Dachverband-Support bekommt diese Permission
  • Specs gründlich schreiben
  • Kunde wegen Übersetzungen informieren
  • Mit angemessener Rolle "durchklicken"
  • CHANGELOG-Eintrag unter "unreleased" unten hinzufügen

Migration Block 4

Datenmigration

  • Aargau
  • Thurgau "Newsletter" Tags nachbessern (siehe MS Teams)

Tipps für CSV aufbereiten

  • Anführungszeichen entfernen (")
  • Newlines entfernen (\n)
  • MMBoName "Account" => "Company", Name zu Company Spalte kopieren

Datum:

Export am Montag 02.05.2022
Migration Mittwoch 04.05.2022 oder Donnerstag 05.05.2022
Schulung findet am Freitag 6. Mai durch Loïc statt

INVOICES: Daterange in Rechnungen

Als Rechnungsteller
möchte ich eine bessere Übersicht der Rechnungen haben und nach Datum eingrenzen können
um sehr lange und unübersichtliche Listen zu verhindern.

Wenn sehr viele Rechnungen vorhanden sind, wird die Liste sehr lang und unübersichtlich. Ein besserer Filter bezüglich Datum soll integriert werden.

Zu prüfen ob generell der Datepicker für das Jahr abgelöst werden kann. Dieser kommt u.a. bei events, messages,

Mockup

grafik

Tech-Spec

  • sinngebende Zielrichtung
  • besondere/bekannte Bedingungen und Grenzfälle
  • technische Einschränkungen
  • Ein- und Ausgabeformate beschreiben
  • Umsetzungsplan ergänzen oder anpassen

ToDo

TECH: Test Setup OIDC für Cloudtech, Unterstützung

damit Cloudtech OIDC Implementieren kann, wird ein Testaccount auf der Integrationsumgebung eingerichtet.
Falls Cloudtech noch Unterstützung bei der Implementation benötigt kann dies ebenfalls auf dieses Ticket gebucht werden.

PEOPLE: Datenabgleich neue/mutierte Person Hitobito -> DONMAN

Wird eine neue Person in Hitobito erfasst oder eine bestehende Person geändert, soll via Webhook ein API Call an DONMAN erfolgen.

Dazu soll als erstes die Basis des Webhook Features im Core implementiert werden. Basis Webhooks

Später sollen auch die Informationen über die Abos der Personen synchronisiert werden. Dies wird aber ergänzend zu diesem Feature mit einem eigenen Issue umgesetzt. #65

Erhält eine Person eine neue Rolle, oder wird eine Rolle entfernt, muss diese aktualisierte Info ebenfalls via Webhook Call an DONMAN gesendet werden.

Offene Punkte

  • soll dieser Abgleich für alle Personen und Firmen in der DB gemacht werden? Oder nur spezifische Gruppen? oder gar Rollen?
    • es sollen sämtliche Personen/Firmen synchronisiert werden
  • Welche Attribute werden an DONMAN gesendet?
    • Siehe Tabelle unten
  • Was passiert wenn eine Person in Hitobito gelöscht wird?
    • Kein automatisiertes Löschen aus DONMAN, in diesem Fall wird der Eintrag manuell gelöscht.

Api DONMAN

Eine Liste der FO Layer IDs wird einmalig aus Hitobito exportiert und in DONMAN importiert. Alternativ kann DONMAN diese Liste auch via API bei Bedarf fetchen. Prüfen welche Option hier Sinn macht.

Mapping Attribute

Hitobito Attribute Description DONMAN Field DONMAN Datatype DONMAN Description
Person#custom_salutation Benutzerdefinierte Anrede (SWW spezifisches Attribut) tdb String
Person#language de, fr, it, en LanguageCode* Int 1: German 2: French 3: Italian 4: English
Person#gender, Person#company Geschlecht oder Firma wenn company AddressCode* Int 1: Mister 2: Wife 7: Family
Person#id PrimaryKey Person OnlineCustomerId Int Customer number internetprovider (if known)
- DonmanCustomerId Int DonMan personal number (if known)
- KbConsId BigInt CH-Private number (if known)
- KbConsHhId BigInt CH-Private Household number (if known)
Person#title Dr., Rechtsanwalt, Lehrer, Kassier, ... Title String Title
Person#first_name Firstname String First name
Person#last_name Lastname* String Last name
- Wifename String Woman's name
Person#company_name Company String Company
- CareOf String c/o field
Person#address Hitobito hat nur ein Feld für Strasse, Nr, c/o usw. Dieses Feld nach Street mappen Street String Street (if there is a street, the information is obligatory, but since there are addresses without street information, we have waived a mandatory check)
- StreetNo String House number (if there is a house number, it is obligatory, but since there are addresses without a street number, we have not made an obligatory check)
- StreetAdd String Additional address
- PobFlag bool P.O. Box (true if a P.O. Box exists, false if not)
- PobNo String P.O. Box number (if this column is used the column POBFlag must be set to true)
Person#zip_code 4242, 3007, auch nicht CH PLZs Zip* String Zip code 4 digits (for CH addresses)
- Zip56 String Zip code digits 5-6 (if known)
Person#town Bern, Thun, ... Town* String City
Person#country CH, DE, ... Country String Country code, if sent empty, "CH" will be used by default by KB
Person#email [email protected] EmailPrivate String Email address private
Person#additional_emails erste zusätzliche E-Mail Adresse falls vorhanden (unabhängig vom Label) EmailBusiness String Email address business
Person#phone_numbers Person phone_number with label 'Privat' if present PhonePrivate String Phone number private (format 999 / 999 99 99)
Person#phone_numbers Person phone_number with label 'Arbeit' if present PhoneBusiness String Phone number business (format 999 / 999 99 99)
Person#phone_numbers Person phone_number with label 'Mobil' if present MobilePrivate String Cell phone number private (format 999 / 999 99 99)
- MobileBusiness String Cell phone number business (format 999 / 999 99 99)
- WebsitePrivate String Website private
- WebsiteBusiness String Website business
Person#birthday Date (Format wird noch durch KB definiert) BirthDate DateTime Date of birth
- Response (SubStructure) Response Substructure for response information (0:n for each Customer main element)
- Subscription (SubStructure) Subscription Substructure for subscription information (0:n for each customer main element)
- Shop (SubStructure) Shop Substructure for store information (0:n for each customer main element)
FO layer ids Liste der FO Layers in welcher die Person eine Rolle hat. Format muss noch definiert werden. Ebenfalls muss definiert werden wie Von/Bis einer Rolle gehandhabt wird. Idealerweise geben wir diese Info mit an DONMAN. Wie handhaben wir es wenn eine Person mehrere Rollen hat mit mehreren von/bis? Attribute (SubStructure) Attribute Substructure for attribute information (0:n for each customer main element)
- MailingGroup (SubStructure) MailingGroup Substructure for MailingGroup information (0:n for each customer main element)

Pflichtattribute Hitobito Person

Folgende Personen Attribute sollen neu Pflichtfelder sein in Hitobito SWW: #73

  • last_name + first_name if NOT #company
  • company_name if #company

TECH: Weitere Visuelle Anpassungen

Design passt schon sehr gut. Folgende Rückmeldung habe ich noch erhalten...

ToDo

  • Gelbe Texte auf weissem Hintergrund sind schwierig zu lesen. Text auf Schwarz ändern
  • Bei Buttons beim Hoover passt das Gelb mit weissem Text

INVOICES: Import offener Rechnungen FOs

für den einmaligen Import pro Fachorganisation (FO) der offenen Rechnungen aus Alabus soll ein automatisierter Import gebaut werden.

Es gibt ungefähr 17 Fachorganisationen und dieser Import wird pro FO einmalig angewendet.

Alabus Daten liegen als Excel-Export vor. Export kann vor dem Import manuell in ein CSV umgewandelt werden.

Als Parameter wird die Gruppen ID des FO Layers in welche die Rechnungen importiert werden sollen angegeben.

Alabus Attribut Inhalt Hitobito Attribut
id Unqiue Alabus Personen ID Wird für die Zuweisung der Person in Hitobito verwendet (person#alabus_id)
Status Rechnungsstatus Es werden nur Rechnungen mit Status offen importiert
Referenznummer Referenznummer Rechnung invoice#esr_number
Rechungsdatum 22.02.2022 invoice#sent_at
Erstellt am 22.02.2022 14:42 invoice#created_at
Kategorien Einzelmitglied, Doppelmitglied, ... invoice_item1#name
Rechnungsbetrag 20.00 invoice_item1#unit_cost, count: 1

Tech-Spec

  • rails import:invoices_fo
    • source datei: $WAGON_ROOT/db/seeds/production/invoices_fo.csv
    • parameter layer_id
  • Pro Importzeile mit Status offen wird eine neue Rechnung in Hitobito erstellt
  • Titel: "Alabus Rechnung" + Alabus Atttribut "Kategorien"
  • Status der importierten Rechnung ist :sent
  • Auch Rechnungen mit Betrag 0.00 werden importiert
  • person über alabus_id / id export Spalte zuweisen
  • Pro Rechnung je ein Item mit Name, unit_cost und count = 1

ToDo

  • Rake-Task import:invoices_fo[layer_id] anlegen
    • source datei: $WAGON_ROOT/db/seeds/production/invoices_fo.csv
    • parameter layer_id
    • Details siehe Tech-Spec

INVOICES: Option für Mitgliederausweis auch auf Sammelrechnung

wie bei den Einzelrechnungen soll die Option für das Drucken des Mitgliederausweises auch auf der Sammelrechnung ergänzt werden. Siehe #57

Beim Erstellen der Rechnungen wird dann also der Mitgliederausweis gedruckt falls die Option ausgewählt ist.

ToDo

  • Anpassen Form für InvoiceList
  • Berücksichtigen Invoice Attrs für Mitgliederausweis
  • CHANGELOG anpassen
  • Specs

PEOPLE: Importe Alabus

Der Import aus Alabus wird in drei Teile aufgeteilt:

1. Import Personendaten SWW

Dieser Import erfolgt einmalig für den Dachverband (SWW) #14

2. Import Personendaten FOs

Für den Import der Personendaten der Fachorganisationen (FO) wird ein eigener Import erstellt: #17

3. Import offene Rechnungen FOs

Nach dem Import der Personendaten einer FO sollen alle offenen Rechnungen nach Hitobito importiert werden #13

Import durchführen

Migration Block 1

Datenmigration:

  • Appenzell Ausserrhoder Wanderwege
  • Schwyzer Wanderwege
  • Zuger Wanderwege

Datum: 12.04.2022

INVOICE: Zusätzliche Stati auf der Rechnung

Als Kassier
möchte ich einsehen, ob eine Rechnung teilweise bezahlt wurde oder ob mehr als der Rechnungsbetrag bezahlt wurden
um entsprechende Mahnungen oder Spendenverdankungen auszulösen.

Neu sollen folgende Stati eingeführt werden:

  • Teilzahlung -> Wenn ein Betrag bezahlt wurde aber die Zahlung noch kleiner als der Rechnungsbetrag ist
  • Zu viel bezahlt -> Wenn die Zahlung höher als der Rechnungsbetrag ist

Der Filter in der Rechnungsansicht invoices entsprechend erweitern.

Mockup

hier folgt ein Mockup ...

Tech-Spec

  • sinngebende Zielrichtung
  • besondere/bekannte Bedingungen und Grenzfälle
  • technische Einschränkungen
  • Ein- und Ausgabeformate beschreiben
  • Umsetzungsplan ergänzen oder anpassen

ToDo

  • Migration erstellen
  • Domainklasse erstellen oder anpassen
  • Model/View/Controller anpassen
  • Specs schreiben
  • Kunde wegen Übersetzungen informieren
  • Mit angemessener Rolle "durchklicken"
  • CHANGELOG-Eintrag unter "unreleased" unten hinzufügen

PEOPLE: Synchronisation DONMAN Abo Daten

Ergänzend zu #50 sollen ebenfalls die Abodaten der Personen nach DONMAN synchronisiert werden.

  • Einmaliger Initialimport in DONMAN dieser Informationen
  • Synchronisation Bidirektional ?

TODO: Dieses Ticket muss vor der Umsetzung erst noch Konzipiert werden.

Grundpaket: Gruppenstruktur, Rollen, Berechtigungen

Ziel: Abbilden der Struktur, Rollen, Berechtigungen

  • Gruppen
  • Rollen
  • Seeds anpassen
  • Fixtures anpassen
  • Basis-Specs sicherstellen
  • Gruppenstruktur in der Integration seeden
  • Setup Github Actions

Gruppen, Rollen, Berechtigungen

Bemerkung:


Schweizer Wanderwege

Support: [admin, finance, layer_and_below_full:, impersonate]
Mitarbeitende: [layer_and_below_full]
Kontakte +
      Kontakt: []

Fachorganisation

Vorstand #Defaultchild
      Präsident: [contact_data, layer_and_below_full]
      Vizepräsident: [contact_data, layer_and_below_full]
      Vorstandsmitglied: [layer_and_below_full]

  Geschäftsstelle #Defaultchild
      Geschäftsführer: [contact_data, layer_and_below_full, finance]
      Kassier: [layer_and_below_full, finance]
      Technischer Leiter: [layer_and_below_full]
      Mitarbeiter: [layer_and_below_full]

  Gremium/Projektgruppe +
      Leitung: [group_and_below_full]
      Mitglied: [group_and_below_read]

  Mitglieder  +
      Aktivmitglied: []
      Passivmitglied: []
      Freimitglied: []
      Organisationen: []
      Partner: []
      Spender: []

  Kontakte +
      Kontakt: []

TECH: Setup der Integrationsumgebung

Domain: sww.puzzle.ch

Setup erfolgt noch auf Openshift 3 (für Openshift 4 gibt es noch zu viele offene Fragen/Punkte)

ToDo

  • Openshift-Projekt
  • Basic setup mit Secrets
  • kustomize-overlay
  • mailtrap
  • dns (sww.puzzle.ch)
  • composition-repo
  • apply-config
  • jenkins-job
  • Credentials im Cryptopus
  • Github Actions

See: #1

PERMISSION: Ergänzen Rolle mit contactdata

IST:
SWW Mitarbeitende: [:layer_and_below_full]
FO Rolle Mitarbeiter: [:layer_and_below_full]

Soll:
SWW Mitarbeitende: [:layer_and_below_full, :contact_data]
FO Rolle Mitarbeiter: [:layer_and_below_full, :contact_data]

Todo:

  • Anpassen von readme.doc im Wagon

PEOPLE: Datenabgleich DONMAN <=> Hitobito

Dieses Epic dient als Übersicht der Datensynchronisation zwischen Hitobito und DONMAN

Übersicht der Schnittstelle

donman

Initialer Datenabgleich Hitobito -> DONMAN

Dieser erfolgt über ein einmalig aus Hitobito exportiertes CSV. #48

JSON API für Personendaten read

JSON API für Personendaten write

Donman pushed regelmässig (z.B. nächtlich) geänderte Adress-Informationen von Personen nach Hitobito. #49

Migration Block 3

Datenmigration

  • Genève Rando
  • Jura Rando
  • Valrando
  • Glarner Wanderwege
  • Obwaldner Wanderwege

Tipps für CSV aufbereiten

  • Anführungszeichen entfernen (")
  • Newlines entfernen (\n)
  • MMBoName "Account" => "Company", Name zu Company Spalte kopieren

Datum: 26. April 2022

PEOPLE: Persistieren Person Abo Nummer

Beim ändern des Feld Abo Nummer wird dies nicht gespeichter. Feld kann auf der Person ausgefüllt und gespeichert werden. Meldung, dass der Datensatz erfolgreich gespeichert wurde erscheint. Jedoch wird der eingegeben Wert weder in der View noch in der Bearbeitungsmaske angezeigt.

TECH: Setup Mehrsprachigkeit

Ziel: Gewünschte Sprachen DE, FR, IT einbauen

  • settings.yml
  • transifex -> eigenes Projekt (für Wagon spezifische Übersetzungen)
  • Kunde berechtigen und instruieren

INVOICE: Ausgabe von Mitgliederausweis

Als Sekretariat
möchte ich für meine Mitglieder ein Mitgliederausweis bedrucken,
um direkt aus Hitobito die Daten verwenden zu können.

Über das Abo den Briefexport anpassen, um ein spezielles PDF zu generieren,
welches auf die Vorlage abgestimmt ist. Dadurch werden die notwendigen Daten
direkt auf das Briefpapier gedruckt.

Als Option zum Briefmodul hinzufügen. Vererbung zum Rechnungsbrief.

Offen zu klären:

  • Gibt es zum Mitgliederausweis immer eine Rechnung? -> beides möglich
  • Definitive Vorlage (Wordvorlage oder PDF)

Mockup

Beispiel auf dem Rechnungsbrief:

image

Ausgabe als PDF. Markierte stellen werden im PDF generiert. Andere Texte und Bilder sind auf dem Briefpapier vorbedruckt.
Mitgliederausweis

Tech-Spec

  • Wiederverwendung des normalen Briefes
  • Mitgliederausweis kann mit oder ohne Rechnung versandt werden
  • Vorlage beachten, ob auch Kopfzeile ausgeblendet werden muss
  • Umsetzung im SWW-Wagon

ToDo

  • Klären, ob Mitgliederausweis nur auf Rechnung erscheint
  • Definitive Vorlage klären (Wordvorlage oder PDF)
  • Migration erstellen
    • add_column :messages, :membership_card, :boolean, default: false, null: false
  • Domainklassen anpassen
    • Export::Pdf::Messages::Letter
    • Export::Pdf::Messages::Letter::Header
  • Model/View/Controller anpassen
    • Checkbox hinzufügen
    • Checkbox in permitted_attrs aufnehmen
  • Specs schreiben
  • Kunde wegen Übersetzungen informieren
  • Mit angemessener Rolle "durchklicken"
  • CHANGELOG-Eintrag hinzufügen

INVOICE: Export Buchungsbeleg

Als Kassier
möchte ich ein Buchungsbeleg exportieren können,
um die Zahlungen in die Buchhaltung zu übertragen

Der Buchungsbeleg soll folgende Informationen enthalten:

Buchungsbeleg

Das Periode kann entsprechend gewählt werden.
Die Beträge sollen aufgrund der Zahlungen der Periode berechnet werden.

Umsetzung als Reporting im WebUI als Table
Zuweisung Payment -> Rechnungsartikel könnte noch speziell werden, da wir das in der DB nicht abbilden. Müsste man also korrekt “interpretieren”.
Sicher nicht unmöglich, muss aber gut getestet werden.

Export in Ticket: #61

Mockup

See hitobito/hitobito#1787

Tech-Spec

Umsetzung soweit verallgemeinerbar im Core.

  • Neuer Eintrag "Auswertungen" im Rechnungen-Menü jedes Layers (linke Navigation, siehe Mockup)
  • Auf diesem neuen Auswertungen-Sheet werden in Zukunft z.B. in Tabs verschiedene Auswertungen abrufbar werden. Für den Moment reicht es aber wenn der Buchungsbeleg direkt ohne Tabs angezeigt wird
  • Datumsbereich als Inputfelder mit Submit-Button
    • Standard ist von "vor einem Monat" bis "heute"
  • Zeilen "Verbandslösung Schweizer Wanderwege", "Druckdatum", "Mitarbeiter" vom Mockup können weggelassen werden
  • Tabelle wird berechnet aus den vollständigen Zahlungen im Datumsbereich in diesem Layer
    • Da nur vollständig bezahlte Rechnungen betrachtet werden, können die Rechnungsartikel einfach summiert werden.
    • Die letzte Zeile ist immer "Überschuss" (excess) was im SWW-Wagon mit "Spenden" übersetzt werden soll
  • Allenfalls Domainklasse Donation auf Payments oder PaymentCollector o.ä. umbenennen und ggf. anpassen
    • in allen Wagons prüfen, ob das noch woanders verwendet wird
  • Da die Rechnungsposten nach Namen gruppiert werden müssen, müsste man möglicherweise einen DB-Index auf invoice_items.name machen. Dies sollte aber kurz getestet werden (sowohl mit kurzen wie mit langen Datumsbereichen). Nicht in jedem Fall ist ein Index besser als keiner.
  • Specs schreiben
  • Kunde wegen Übersetzungen informieren
  • Mit angemessener Rolle "durchklicken"
  • CHANGELOG-Eintrag unter "unreleased" unten hinzufügen

INVOICE: Anpassungen Ausgabe von Mitgliederausweis

Anpassungen zu Issue #27

  • Text oben rechts: Anstelle Leserausweis WANDERN.CH nur Mitgliederausweis
  • Rechnungsbrief kein Betreff als Titel drucken, sonst gibt es für den Text zu wenig Platz. Der Brief soll aber der Titel enthalten.

Weiteres Feedback von Loic:

image.png

  • Ich bin nicht sicher ob Oli das schon mit dir besprochen hat, aber unsere CICD Schriften sind Cardo und Montserrat. Wie einfach/ kompliziert wäre es diese für den Brief (und die Rechnungen) zu verwenden?
  • Bei den Anredeoptionen müsste man noch "Guten Tag" und "Sehr geehrte" hinzufügen
  • Anzeige Anrede falls Option ausgewählt

INVOICE: Anpassungen Rechnungen mit Position ohne Total

Anpassungen zu Issue #26

Umsetzung über eigener Artikel oder als Checkbox

Anpassungen an der View

  • Label von "Ohne Total" zu 'Position "Spende" anzeigen' ändern (nur im SWW Wagon)
  • Checkbox unter die Rechnungsposten verschieben (siehe Mockup)

Mockup
image

Anpassungen an am PDF

  • Subtotal anzeigen und berechnen
  • Spende als unabhängiger Posten nach dem Subtotal
  • Total anzeigen aber ohne Betrag
  • Text "Spende" muss übersetzbar sein

Mockup

image

ToDo

  • Domainklassen im Wagon anpassen
    • Sww::Export::Pdf::Invoice::Articles
      • Subtotal berechnen und anzeigen
      • Spende als Artikel anzeigen
      • Total ohne Betrag anzeigen
  • Übersetzung für "Spenden" ermöglichen
  • View anpassen
    • Checkbox verschieben
    • Label anpassen (Übersetzung "Position $spenden_übersetzung")
  • Specs anpassen und schreiben
  • Export manuell testen/mit angemessener Rolle durchklicken

PEOPLE: CSV import improvements

Für die beiden Imports people_fo und invoices_fo sollen noch folgende Verbesserungen angebracht werden:

1. Auflisten der Einträge/Rows die nicht importiert werden konnten

Am Ende des Import Tasks soll ausgegeben werden wieviele Rows das erfolgreich importiert werden konnten. 3454/3542
Ausserdem soll eine Liste mit den fehlenden Einträgen ausgegeben werden.

2. Erneuter Run des Import Tasks

Hat man die fehlenden Einträge gefixt, soll es möglich sein das gleiche CSV mit den korrigierten nochmals zu importieren. Es soll geprüft werden ob ein Eintrag bereits existiert. Als ID wird die alabus_id bzw. bei den Rechnungen die esr als Referenz verwendet. Einträge die noch nicht existieren sollen erstellt werden.

Momentan gibt es side effects wenn man die gleiche Datei ein zweites mal importiert. z.B. werden bei Personen Rollen und Additional E-Mails mehrfach assigned.

3. Rechnungsstatus Teilbezahlt

wird ignoriert, nur die mit Status offen importieren wie bereits implementiert.

ToDo

  • Import auf Integration Personen Daten UR, Feedback von Loic
  • Falls i.o. Import Personendaten UR auf Produktion, Vorher Prod Releasen
  • Import Rechnungen und Personen Daten LU, Feedback von Loic zu Rechnungsimport
  • Implementation inkl. Testing des Reporting für den people_fo import
  • Implementation inkl. Testing des Reporting für den invoices_fo import
  • Implementation inkl. Testing re-run people_fo import
  • Implementation inkl. Testing re-run invoices_fo import
  • Testen des Imports mit allen 4 geplanten Imports FOs (LU, NW, GR, UR)

PEOPLE: CSV Import Personendaten FOs

für den einmaligen Import pro Fachorganisation (FO) der Personendaten aus Alabus soll ein automatisierter Import gebaut werden.

Es gibt ungefähr 17 Fachorganisationen und dieser Import wird pro FO einmalig angewendet.

Alabus Daten liegen als Excel-Export vor. Export kann vor dem Import manuell in ein CSV umgewandelt werden.

Dieser Import ergänzt den Import Dachverband: #14

Als Parameter wird die Gruppen ID der Mitgliedergruppe (Type Group::Mitglieder) in welche die Personen importiert werden sollen angegeben. Alle Personen erhalten die Rolle Aktivmitglied

Zusätzliche Import-Felder:

Alabus Attribut Inhalt Hitobito Attribut
id (genauen Name klären) Unique Alabus Personen ID wird verwendet um die Person in Hitobito zu assignen (person#alabus_id)
Abo1End Abo Ende d.o. Rolle Group::Mitglieder::MagazinAbonnent, :deleted_at
Abo1Number Abonummer Magazin Person#magazin_abo_number #16
Abo1 Print-Abo, Kombi-Abo Tag auf Person abo:print, abo:kombi
PrimaryCategory Einzel, Doppelmitglied category:Einzel, category:Doppelmitglied
MemberEntryDate Eintrittsdatum Aktivmitglied#created_at
MemberExitDate Austrittsdatum Aktivmitglied#deleted_at
PrimaryCommChannel Tag Newsletter falls Wert Newsletter in Exportspalte
NameAddOn weitere Person im gleichen Haushalt Neues Attribut auf Person#name_add_on, string, null: true,
Title Titel Person neues Attribut title auf Person
PrimaryAddressCountryLICTranslated Land z.B. Schweiz, immer deutsche Bezeichnung person#country, default: CH

Tech-Spec

  • Basiert auf #14
  • rails import:people_fo
    • source datei: $WAGON_ROOT/db/seeds/production/people_fo.csv
    • parameter group_id
  • rename import:people to import:people_sww (damit klar unterschieden wird)
  • Zusätzliches Attribut person#title, :string, null: true,
    • Editierbar
    • Positioniert nach Name, Vorname im UI
    • wird in allen Personenexport mitexportiert
  • Zusätzliches Attribut person#name_add_on, :string, null: true
    • Editierbar
    • Namenszusatz
    • Positioniert nach title im UI
    • wird in allen Personenexport mitexportiert
  • Neue Rolle Group::Mitglieder::MagazinAbonnent
  • Es kann vorkommen das eine E-Mail Adresse in mehreren FO exports vorhanden ist.
    • Falls eine email bereits als haupt-email vergeben ist, bei der aktuell zu importierenden person die hautp-email leer lassen und nur eine zusätzliche e-mail erstellen. Die Haupt-email ist unique und wird als login verwendet.
    • Leider können wir die beiden Personeneinträge mit gleicher E-Mail nicht zusammenmergen und verschiedene Rollen der gleichen Person assignen. Es darf nicht ersichtlich sein das eine Person in einer anderen FO Mitglied ist (auflistung rollen)

ToDo

Migration Block 2

Datenmigration:

  • Wanderwege beider Basel
  • Schaffhauser Wanderwege
  • Solothurner Wanderwege
  • Thurgauer Wanderwege

Datum: 19. April 2022

SETTING: Englisch als zusätzliche GUI Sprache

Als Benutzer
möchte ich Hitobito auch auf Englisch bedienen können.

Tech-Spec

  • sinngebende Zielrichtung
  • besondere/bekannte Bedingungen und Grenzfälle
  • technische Einschränkungen
  • Ein- und Ausgabeformate beschreiben
  • Umsetzungsplan ergänzen oder anpassen

ToDo

  • Migration erstellen
  • Domainklasse erstellen oder anpassen
  • Model/View/Controller anpassen
  • Specs schreiben
  • Kunde wegen Übersetzungen informieren
  • Mit angemessener Rolle "durchklicken"
  • CHANGELOG-Eintrag unter "unreleased" unten hinzufügen

PEOPLE: Aufräumen Mitgliedernummer

Momentan gibt es viele Mitgliedernummern, welche doppelt vergeben sind, davon auch über 1000 welche an mehrere aktive Personen vergeben sind. Für neue Personen wurden ausserdem Mitgliedernummern über 300'000 vergeben (Mitgliederanzahl ist ca. 25'000). Zudem funktioniert aktuell der CSV-Import nicht, weil die Logik zur Vergabe von neuen Mitgliedernummern nicht auf das gleichzeitige Erstellen mehrerer Personen in einer Transaktion ausgelegt ist.

Die SWW möchte gerne...

  • eindeutige Mitgliedernummern
  • generell möglichst tiefe Mitgliedernummern
  • bei möglichst wenigen von früher importierten Personen die Nummer ändern, weil die Kantone sich sonst aufregen
  • dass der CSV-Import funktioniert

Nach Absprache mit Loïc setzen wir folgende Lösung um:

TODO

  • Spalte member_number auf manual_member_number umbenennen
    • sicherstellen dass manual_member_number nicht in Exporten und in Index-, Show- und Edit-Ansichten auftaucht
    • Problematische Logik before_validation, set_incremented_member_number und next_member_number (welche nicht transaction-safe ist und race conditions hat) sowie validates :member_number, uniqueness entfernen (wird später via validates_by_schema erledigt, siehe letzter Punkt im TODO)
  • Neue Methode member_number auf Person welche die manual_member_number ausgibt falls vorhanden, oder andernfalls die id + 300_000
  • manual_member_number bei allen Personen ohne aktive Rolle auf NULL setzen
  • manual_member_number welche über 300'000 sind auf NULL setzen
  • Alle dann noch verbleibenden doppelt verwendeten manual_member_numbers heraussuchen
    • Für jede doppelt verwendete Nummer bei allen bis auf eine Person die manual_member_number auf NULL setzen. D.h. Wenn manual_member_number 1234 von Personen mit IDs 80, 520 und 732 verwendet wird, zum Beispiel die manual_member_number bei den Personen 520 und 732 auf NULL setzen.
    • Achtung: Vorher noch eine Liste mit allen in diesem Schritt veränderten Personen wegspeichern, und an Loïc zustellen, sodass er die Kantone entsprechend informieren kann bei welchen Personen die Mitgliedernummern geändert haben
  • Unique Datenbankindex auf der Spalte manual_member_number (nicht eine Rails Validation, die Werte müssen wirklich zwingend unique sein)

TECH: Grundpacket Basissystem für SWW

Ziel: Aufbau Grundpaket/Umgebung für die Schweizer Wanderwege

Inhalt:

  • Neues Repo erstellen: hitobito_kunde , About ergänzen, Lizenz festlegen
  • Wagon erstellen #4
  • Setup der Integrationsumgebung #2
  • Gruppenstruktur, Rollen, Berechtigungen #5
  • Visuelle Anpassungen #6
  • Resourcen bestellen bei /sys
  • Mehrsprachigkeit #7
  • Produktionsumgebung #3
  • DNS Einstellungen Kundenseite
  • Wartung und Support

INVOICES: Export Buchungsbeleg als XLSX

Daten aus dem Buchungsbeleg #39 sollen als XLSX exportiert werden können. Zukünftig können noch weitere Formate dazukommen.

Tech-Spec

  • Export von Rechnungsartikel(-daten) und Kontostelle
  • weitere Formate können folgen, also schonmal alles, was format-spezifisch ist, getrennt halten

Fragen

  • Format xlsx oder xls? -> xlsx
  • Headerzeilen (Kriterien, Erstellungsdatum, Erstellender) auch aufnehmen? -> Ja auch ein Header einführen
  • grafische Formatierung ähnlich wie Ausdruck halten? -> Keine Anforderung. Generische Tabelle
  • andere Formate: eher CSV oder eher anderes PDF? -> Nicht Inhalt von diesem Ticket. Wird in einem Folgeticket spezifiziert, wenn gewünscht

Mockup

ToDo

  • Domainklasse erstellen oder anpassen
    • Tabular-Export mit List und Row
    • Format: xlsx
    • Headerzeilen (Kriterien, Erstellungsdatum, Erstellender) auch aufnehmen
    • grafische Formatierung: Keine Design-Anforderung. Generische Tabelle
  • View/Controller anpassen
    • Export ermöglichen
  • Specs schreiben
  • Mit angemessener Rolle "durchklicken"
  • CHANGELOG-Eintrag unter "unreleased" unten hinzufügen

PEOPLE: Datenimport Alabus

Konzeptionsticket:

Die Pesonendaten sollen aus Alabus importiert werden:

✔️ wird importiert/verwendet
wird nicht in Hitobito übernommen
Verwendung muss geklärt werden

Status Feld Inhalt Hitobito Attribut
Attributname Export Bezeichnung: [mögliche, Werte, leer, ... weitere] Attribut/Abbildung in Hitobito
Name Name/Vorname Kombi
NameReverse Vorname/Name Kombi
✔️ MemberNumber Mitgliedernummer: [123456, ...] die aktuellen Mitgliedernummern müssen übernommen werden
✔️ NameAddOn Zusatzname: [leer] wird verwendet für Zusatzinfo (Förster, Kinderarzt, Departement, etc.)
✔️ Title Titel: [Dipl. Natw. ETH Zürich, ..., leer]
✔️ Salutation Anrede: [Herr, Frau]
✔️ FirstName Vorname: [Patricia, Olivia, ...] Person#Vorname
✔️ LastName Nachname: [Gloor, Marx, ...] Person#Nachname
✔️ Account Verband/Verein: [Schweizer Wanderwege]
✔️ Company Partnerfirma: [leer]
✔️ BirthDate Geburtsdatum: [17.11.1978, leer]
✔️ BirthMonth Geburts-Monat: [April, ..., leer]
✔️ Age Alter: [42, 67, ..., leer] wird in Hitobito automatisch anhand Geburtsdatum berechnet
AgeGroup Jahrgang: [1933, 1988, ..., leer] Aus Geburtsdatum ableiten falls benötigt
Nationality Nationalität: [leer] verwendet?
ContactStatus Status: [Aktiv] verwendet? Zweck?
ContactType Typ: [Geschäftsperson, Privatperson, leer]
✔️ Language Sprache: [Deutsch, leer] weitere Werte?
IsMember Ist Mitglied: [ja, nein]
✔️ MainPhone Telefon: [031 111 00 00, +41 31 111 00 00, ..., leer]
✔️ Mobile Mobile: [079 000 00 11, +41 79 000 00 11, ..., leer]
✔️ Email Email: [[email protected], ..., leer] Person#Haupt-E-Mail
✔️ Web Web: [leer] verwendet?
NumberAHV AHV Nummer: [leer] verwendet?
SomeUniqueNumber Mögliche eindeutige Nummer: [leer] verwendet?
NoAdvertising keine Werbung: [ja, nein]
NoInformations keine Informationen: [ja, nein]
✔️ PrimaryAddressAddressLine1 Strasse/Nr: [Aespifeld 42, ..., leer] Person#Adresse
PrimaryAddressAddressLine2 Postfach: [leer], weitere Werte? ggf. in Person#Adresse anfügen
✔️ PrimaryAddressZip PLZ: [4242, leer] Person#PLZ
✔️ PrimaryAddressCity Ort: [Bern, ..., leer] Person#Ort
PrimaryAddressCantonLICTranslated Kanton: [BE, SO, ..., leer]
PrimaryAddressCountryLICTranslated Land: [Schweiz, ...,leer]
PrimaryAddressAddressTypeLICTranslated Typ: [Geschäftlich, leer]
✔️ BillingAddressAddressLine1 Rechnungsadresse Strasse/Nr: [leer] Hat Hitobito Möglichkeit 2. Adresse zu erfassen?
BillingAddressAddressLine2 Rechnungsadresse Postfach: [leer]
BillingAddressZip Rechnungsadresse PLZ: [leer]
BillingAddressCity Rechnungsadresse Ort: [leer]
BillingAddressCantonLICTranslated Rechnungsadresse Kanton: [leer]
BillingAddressCountryLICTranslated Rechnungsadresse Land: [leer]
BillingAddressAddressTypeLICTranslated Rechnungsadresse Typ: [leer]
ShippingAddressAddressLine1 Versandadresse Strasse/Nr: [Rheingasse 42, ..., leer]
ShippingAddressAddressLine2 Versandadresse Postfach: [leer]
ShippingAddressZip Versandadresse PLZ: [3303, ..., leer]
ShippingAddressCity Versandadresse Ort: [Bülach, ..., leer]
ShippingAddressCantonLICTranslated Versandadresse Kanton: [BE, ..., leer]
ShippingAddressCountryLICTranslated Versandadresse Land: [Schweiz]
ShippingAddressAddressTypeLICTranslated Versandadresse Typ: [Privat, leer]
MainAddressAddressLine1 Hauptsitzadresse Strasse/Nr: [leer]
MainAddressAddressLine2 Hauptsitzadresse Postfach: [leer]
MainAddressZip Hauptsitzadresse PLZ: [leer]
MainAddressCity Hauptsitzadresse Ort: [leer]
MainAddressCantonLICTranslated Hauptsitzadresse Kanton: [leer]
MainAddressCountryLICTranslated Hauptsitzadresse Land: [leer]
✔️ MainAddressAddressTypeLICTranslated Hauptsitzadresse Typ: [leer]
SpecialAddressAddressLine1 Spezialadresse Strasse/Nr: [leer]
SpecialAddressAddressLine2 Spezialadresse Postfach: [leer]
SpecialAddressZip Spezialadresse PLZ: [leer]
SpecialAddressCity Spezialadresse Ort: [leer]
SpecialAddressCantonLICTranslated Spezialadresse Kanton: [leer]
SpecialAddressCountryLICTranslated Spezialadresse Land: [leer]
SpecialAddressAddressTypeLICTranslated Spezialadresse Typ: [leer]
PrimaryBankPostAccountNumber
PrimaryBankPostIban
PrimaryBankPostInstituteName
PrimaryBankPostInstituteLocation
PrimaryBankPostClearingNumber
PrimaryBankPostMwstNumber
✔️ Abo1
✔️ Abo1Start
✔️ Abo1End
✔️ Abo1Number
Abo1Comment
Abo2
Abo2Start
Abo2End
Abo2Number
Abo2Comment
Abo3
Abo3Start
Abo3End
Abo3Number
Abo3Comment
Abo4
Abo4Start
Abo4End
Abo4Number
Abo4Comment
✔️ Id id: [abcd3jl-maabb5-kreko15i-1-aa6b4rbe-gxn, ...] Neues Feld alabus_id, :text
✔️ Description Beschreibung: [öisi Putzfrau, ab Dezember, ..., leer]
✔️: PrimaryCommChannel Kommunikationen: [[email protected], +41 79 023 45 67, leer]
Fax Fax: [leer]
✔️: PrimaryNote Notizen: [öisi Putzfau, ..., leer]
✔️: GlobalUniqueId Identifikation: [123456, ...]
✔️ MemberEntryDate Eintrittsdatum: [15.1.1999, ..., leer]
✔️ MemberExitDate Austrittsdatum: [leer]
DeathDate Verstorben: [leer]
PrimaryCategory
AesUser
PrimaryBankPost
TextField1
TextField2
TextField3
TextField4
DateField1
DateField2
DateField3
DateField4
IntegerField1
IntegerField2
CheckBox1 Checkbox 1: [nein]
CheckBox2 Checkbox 2: [nein]
NumberField1
NumberField2
MultilineField1
MultilineField2
AdditionalSelect1
AdditionalSelect2
PrimaryAdditionalMultiSelect Multi-Auswahlwert: [Newsletter SWW, leer]

INVOICE: Rechnungen mit Position ohne Total

Als Rechnungssteller
möchte ich eine Rechnung erstellen, welche Positionen enthält aber kein Total oder Betrag aufweist,
um dem Rechnungsempfänger offen zu lassen, welchen Betrag er einzahlt.

In diesem speziellen Fall soll kein Total auf der Rechnung und kein Betrag im QR Code angezeigt werden. Alte EZ können vernachlässigt werden

Möglichkeiten zur Umsetzung:

  • Beim erstellen der Rechnung wählen ob Total und Rechnungsbetrag angezeigt werden soll oder nicht.

Offen zu klären:

  • Soll im System ein Rechnungsbetrag geführt werden oder soll der Rechnungsbetrag im System auch leer sein.
  • Explizit definieren als Einstellung auf der Rechnung "Rechnung mit/ohne Totalbetrag"
  • Bewusster Entscheid, Rechnung wird unverständlicher, Rechnungsempfänger muss Betrag eingeben.

Mockup

Beispiel eines PDF:

Screenshot from 2022-04-04 08-57-32

Update zum Bild: MWSt muss auf dem PDF bleiben.

Tech-Spec

  • Die Rechnung wird als explizit "ohne Total" markiert
  • ein hinweisender Rechnungsposten "Spende" ist möglich, aber nicht zwingend
  • Spenden sollen so suggeriert und ermöglicht werden
  • Der Rechnungsbetrag wird intern weiter gespeichert
  • Die Rechnung gilt damit weiter als bezahlt, wenn mindestens der Rechnungsbetrag gezahlt wurde. Spenden/Überzahlungen sind bisher auch schon möglich.
  • Eine Rechnung "ohne Total" enthält keine Zwischenbetrag und keinen Gesamtbetrag.
  • Die Mehrwertsteuer wird weiterhin angezeigt und bezieht sich (wie bisher) auf die Summe der Rechnungsposten mit Betrag.
  • Die QR-Rechnung enthält keinen Betrag.
  • Es ergibt sich hiermit kein variabler Spendenaufruf mit pro Empfänger unterschiedlichem Betrag, sondern ein "leerer" Spendenaufruf, der für alle Empfänger gleich ist.
  • Es gibt bereits Rechnungen ohne Betrag: hitobito/hitobito_die_mitte#148

ToDo

  • Migration erstellen
    • add_column :invoices, :hide_total, :boolean, null: false, default: false
  • Domainklassen anpassen
    • Export::Pdf::Invoice::Articles
      • Gesamt- und Zwischenbetrag ggf. ausblenden
    • Export::Pdf::Invoice::PaymentSlipQr
      • Betrag aus QR-Code ggf. entfernen
    • Export::Pdf::Invoice::PaymentSlip
      • Betrag für Codierzeile soll auch leer sein, analog zum QR Code
  • Model/View/Controller anpassen
    • Checkbox anzeigen
    • Checkbox in permitted_attrs aufnehmen
  • Specs schreiben
  • Kunde wegen Übersetzungen informieren
  • Mit angemessener Rolle "durchklicken"
  • CHANGELOG-Eintrag hinzufügen

MESSAGE: Position Adresse mittels Offset definieren

Als Benutzer welcher ein Brief oder Rechnungsbrief erstellt
möchte ich die Position der Adresse anpassen können
damit sie in mein Couvert oder exakt auf mein Briefpapier passt

Neu soll in den Einstellungen der Gruppe ein Offeset für die Adresse definiert werden können. Bei den SWW betrifft dies auch den Mitgliederausweisteil.

Dieses Offset soll für Rechnungen, Briefe und Rechnungsbriefe berücksichtigt werden. Das Offset soll sowohl positiv wie negativ sein. Eingabe in Millimeter.

Mockup

Ein Beispiel wie es Smallinvoice gelöst hat:

image

Tech-Spec

  • Umsetzung im SWW Wagon
  • Ausschliesslich die Adresse soll von diesen Offsets betroffen sein, alles andere im Brief / in der Rechnung nicht! Sonst öffnen wir uns für endlose Bugs wegen Brief-Layouts für die es keine generische Lösung gibt.

ToDo

  • 2 neue Felder left_address_offset und top_address_offset in GroupSetting einfügen, aber nur im SWW Wagon
  • 2 neue Felder für den Mitgliederausweisteil left_TBD_offset und top_TBD_offset in GroupSetting einfügen, aber nur im SWW Wagon
  • Migration erstellen
  • PDF Rendering anpassen so dass es diese Offsets berücksichtigt
    • Brief / Rechnungsbrief rendering
    • Rechnung rendering
    • Sowohl die Adress-Offsets wie auch die Mitgliederausweis-Offsets
  • Specs schreiben
  • Kunde wegen Übersetzungen informieren
  • Mit angemessener Rolle "durchklicken"
  • CHANGELOG-Eintrag unter "unreleased" unten hinzufügen

PEOPLE: CSV Import Personendaten Alabus SWW

für den einmaligen Import der Personendaten des Dachverbandes (SWW) aus Alabus soll ein automatisierter Import gebaut werden.

Alabus Daten liegen als Excel-Export vor. Export kann vor dem Import manuell in ein CSV umgewandelt werden.

Alle Personen werden in die Root Untergruppe mit dem Namen 'Kontakte' importiert. Rolle: Kontakt (Group::Kontakte::Kontakt)

Alabus Attribut Inhalt Hitobito Attribut / Entity
id Alabus Unique ID Neues Attribut: alabus_id (:text), unique, null: true #16
MemberNumber Mitglieder-Nummer Neues Attribut: member_number (:integer), not unique #16
Salutation Herr, Frau, weitere Mapping auf gender falls Herr, Frau, sonst Freitext = original Wert, feld custom_salutation #16
FirstName Vorname Person#first_name
LastName Nachname Person#last_name
Company Firmenname Person#company_name (nur falls MMBoName Company)
MMBoName Contact, Company Person#company true falls Company
BirthDate Geburtsdatum Person#birthday
Language Sprache: Deutsch, Französisch, Englisch, Italienisch Neues Attribut: language, default DE, not null, hitobito/hitobito#1663
MainPhone Telefonnummer wenn Person: phone_number privat, wenn Company: phone_number Arbeit
Mobile Mobilnummer phone_number Mobil
Email E-Mail Adresse email (Haupt-E-Mail)
Web Internetadresse social_account (Webseite)
PrimaryNote Notiz neuer Note Eintrag für Person
PrimaryAddressAddressLine1 Strasse Person#address (line1)
PrimaryAddressAddressLine2 Adresszusatz Person#address (line2)
PrimaryAddressZip PLZ Person#zip_code
PrimaryAddressCity Ort Person#town

Tech-Spec

ToDo

PEOPLE: Initialer Datenabgleich Hitobito -> DONMAN

Der Export soll via Web UI gemacht werden und den Personen CSV Export Alle Angaben verwenden.

Beispielexport mit Dummy-Daten

Folgende Felder werden im aktuellen Alle Angaben Export exportiert:

Fixe Felder

Vorname, Nachname, Firmenname, Übername, Firma, Haupt-E-Mail, Adresse, PLZ, Ort, Land, Geschlecht, Geburtstag, Zusätzliche Angaben, Sprache, Benutzerdefinierte Anrede, Abo # Magazin, Titel, Namenszusatz, Hauptebene, Rollen, Tags, Id

Das Feld Id entspricht dem Hitobito Personen Primärschlüssel und ist zentral für die eindeutige Identifikation von Personen.

Dynamische Felder

folgende Kontakt-Felder (E-Mail, Telefonnr, usw) werden nach den verwendeten Benutzerlabels (hier z.B. MSN, Vater, usw) exportiert:

Weitere E-Mail Vater, Weitere E-Mail Arbeit, Weitere E-Mail Mutter, Weitere E-Mail Andere, Telefonnummer Privat, Telefonnummer Arbeit, Telefonnummer Vater, Telefonnummer Mobil, Telefonnummer Mutter, Social Media Adresse Andere, Social Media Adresse Facebook, Social Media Adresse MSN, Social Media Adresse Webseite, Social Media Adresse Skype

Initialexport DONMAN

Gemäss Feedback von KB kann der Export so verwendet werden und es sind keine weiteren Anpassungen mehr nötig.

Informationen über die verwendeten Rollen bezieht DONMAN via die neue JSON API Schnittstelle

SUCHE: Nach Mitgliedernummer und Abonummer suchen

Nach Mitgliedernummer und Abonummer suchen

Als Benutzer,
möchte ich eine Person aufgrund der Mitgliedernummer oder Abonummer suchen,
um eine Person schnell zu finden.

Neu soll eine Personen gefunden werden. Suchkriterium sind:

  • Mitgliedernummer
  • Abonummer

Tech-Spec

  • Umsetzung im Wagon, da diese Attribute nur beim SWW vorhanden sind
  • Hauptsuche soll erweitert werden

ToDo

  • Suchindex PersonIndex erweitern
    • Mitgliedernummer member_number
    • Abonummer magazin_abo_number
  • Specs schreiben
  • Mit angemessener Rolle "durchklicken"
  • CHANGELOG-Eintrag unter "unreleased" unten hinzufügen

PEOPLE: Neue Attribute Person

Im SWW Wagon sollen folgende Custom Attribute auf der Person erstellt werden:

  • alabus_id, string, null: true, unique: true
    • wird im UI nicht angezeigt
    • readonly attribut
    • dient als Identifikator für weitere Imports aus Alabus (z.B. Rechnungen)
  • member_number (Mitglieder-Nummer), :integer, unique: false, null: false, attr_readonly
    • für neue Entries wird dieser Wert automatisch inkrementiert, 300'000 als Startwert
    • kann nicht manuell erfasst/editiert werden
  • custom_salutation (Benutzerdefinierte Anrede), :string, null: true
  • magazin_abo_number (Abonummer Magazin): :string, null: true
  • language: hitobito/hitobito#1663

ToDo

  • DB Migration mit neuen Attributen erstellen
  • übersetzung DE für Attribute
  • Autoinkrement für member_number implementieren

MESSAGE: Adresse links/rechts als Gruppeneinstellungen

Als Rechnungssteller oder Briefersteller
möchte ich auswählen können ob die Adresse links oder rechts gedruckt angezeigt werden soll,
um auf meine Individuelle Gruppen Eigenschaften reagieren zu können.

Dies Anpassungen sollen für Briefe, Rechnungsbriefe und Rechnungen gelten.

Exakte Positionierung der Adresse wird noch geliefert.

Mockup

Beispiel über die Konfiguration in der Gruppeneinstellungen (nur Layer):

image

Tech-Spec

  • Neue GroupSetting messages_letter_address_position (gültig für Briefe, Rechnungsbriefe und Rechungen)
    • Neuer Enum Typ mit Radio Buttons: :left, :right
  • getter für Position der Address Bounding Box (core)
  • prüfen ob die Changes Impakt auf Rechnungsanpassungen in anderen Wagons hat (z.B. die Mitte)

ToDo

  • GroupSetting messages_letter_address_position im Core erstellen (default :right), neuen Typ Enum erstellen
  • Getter für Positionierung Adress Box mit berücksichtigung left/right:
    • Für Briefe
    • Für Rechnungsbriefe
    • Für Rechnungen
  • Spec für Adressposition Links erstellen
  • Anpassungen im SWW Wagon
    • Positionierung Adresse rechts gemäss aktuellem Template
    • Positionierung Adresse links gemäss neuen Angaben
    • Positionierung Mitgliederausweis auf der gegenüberliegenden Seite

INVOICE: Anpassungen Rechnungen

Für einen dringenden Rechnungslauf braucht es folgende Anpassungen

  • Zeile mit der MwSt weg lassen
  • Empfänger Adresse links anstelle rechts
  • Export läuft bei 150 Rechnungen in ein Timeout. Kann dies temporär erhöht werden?

Umsetzung im Wagon SWW

Mockup

Screenshot from 2022-04-14 22-25-08

Todo

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.