Implement GEWISDB member sync

[rinkp]

GEWISDB has an API available for retrieving member information: https://github.com/GEWIS/gewisdb/blob/main/openapi.yaml (import this into your favourite editor such as Insomnia)

My proposal is to request updated data for each member that has a linked GEWIS account each day instead of only during sign-in.

• [ ] Sync all existing users daily, this includes updating their name and especially email address based on their membership number
• [ ] Disable users when their membership has expired. No POS sign-in, no "charge to", no web sign-in, nothing
• [ ] Send users a notification when their account is disabled and they still have a non-zero balance
• [ ] CC the bacpm in above notification if the non-zero balance is <€0, so they can make a final invoice (GH-139) if there is no reply
• [ ] Disable negative balances when a member no longer is a member, but a graduate (and thus no longer has type ordinary (studying at TUe), external (active member of studying elsewhere), or honorary). The TOS allows this, for a reason.

[rinkp]

I expect you need ApiPermissions::HealthR to check if API is available, ApiPermissions::MembersR to see members, and ApiPermissions::MembersPropertyType to see the membership type. Please include what permissions are needed in README.md, so this information does not get lost

[tomudding]

• Sync all existing users daily, this includes updating their name and especially email address based on their membership number

@JustSamuel the database recalculates its information around 01:00 CET, this can take up to 30 minutes to complete. Then gewis.nl syncs around 02:00 CET, so I recommend syncing somewher after 02:30 CET. That way you have up-to-date information and do not disturb other systems.

I shared an API with you (earlier this week) that has the permissions Rink mentioned, note that that key only works on the test environment.

[rinkp]

I expect you need ApiPermissions::HealthR to check if API is available, ApiPermissions::MembersR to see members, and ApiPermissions::MembersPropertyType to see the membership type. Please include what permissions are needed in README.md, so this information does not get lost

With the introduction of the new API functionality, you need

• ApiPermissions::HealthR
• ApiPermissions::MembersR
• ApiPermissions::MembersPropertyType
• ApiPermissions::MembersEmail
• ApiPermissions::MembersAge18

[rinkp]

Please take note that for consistency with the website, responses now look like this

{
  "data": [
    {
      "lidnr": 8000,
      "full_name": "Timo de Teststudent",
      "initials": "T.",
      "given_name": "Timo",
      "middle_name": "de",
      "family_name": "Teststudent",
      "generation": 2022,
      "hidden": false,
      "deleted": false,
      "expiration": "2023-07-01T00:00:00+02:00",
      "birthdate": "2023-07-01T00:00:00+02:00",
      "is_16_plus": true,
      "is_18_plus": true,
      "is_21_plus": true
    },
    {
      "lidnr": 8000,
      "full_name": "Timo de Teststudent",
      "initials": "T.",
      "given_name": "Timo",
      "middle_name": "de",
      "family_name": "Teststudent",
      "generation": 2022,
      "hidden": false,
      "deleted": false,
      "expiration": "2023-07-01T00:00:00+02:00",
      "email": "example@gewis.nl"
    },
    {
      "lidnr": 8000,
      "full_name": "Timo de Teststudent",
      "initials": "T.",
      "given_name": "Timo",
      "middle_name": "de",
      "family_name": "Teststudent",
      "generation": 2022,
      "hidden": false,
      "deleted": false,
      "expiration": "2023-07-01T00:00:00+02:00",
      "organs": [
        {
          "organ": {
            "id": 1,
            "abbreviation": "Testorgaan"
          },
          "function": "Lid",
          "installDate": "0001-01-01T00:00:00+00:00",
          "dischargeDate": null,
          "current": true
        }
      ]
    },
    {
      "lidnr": 8000,
      "full_name": "Timo de Teststudent",
      "initials": "T.",
      "given_name": "Timo",
      "middle_name": "de",
      "family_name": "Teststudent",
      "generation": 2022,
      "hidden": false,
      "deleted": false,
      "expiration": "2023-07-01T00:00:00+02:00",
      "keyholder": true
    },
    {
      "lidnr": 8000,
      "full_name": "Timo de Teststudent",
      "initials": "T.",
      "given_name": "Timo",
      "middle_name": "de",
      "family_name": "Teststudent",
      "generation": 2022,
      "hidden": false,
      "deleted": false,
      "expiration": "2023-07-01T00:00:00+02:00",
      "membership_type": "ordinary"
    },
    {
      "lidnr": 8000,
      "full_name": "Timo de Teststudent",
      "initials": "T.",
      "given_name": "Timo",
      "middle_name": "de",
      "family_name": "Teststudent",
      "generation": 2022,
      "hidden": false,
      "deleted": false,
      "expiration": "2023-07-01T00:00:00+02:00"
    }
  ]
}

[JustSamuel]

I made a ts-client for the api here: https://github.com/GEWIS/gewisdb-ts-client

[JustSamuel]

Should graduates not still have the right to have a negative balance?

3.2 Negative balances Only GEWIS members and legal entities who have been granted access by the BAC are allowed to have a negative balance.

@rinkp

[rinkp]

Should graduates not still have the right to have a negative balance?

The quoted text includes only GEWIS members. Those are ordinary, external and honorary members. Graduates are no members and thus not included in the set of members.

The goal was to reduce the phenomenon that we have seen in the past where graduates only show up once and subsequently never increase their balance regardless of how many reminders they receive. This sadly is a case of a few people who spoil it for the rest but ultimately won't hinder graduates too much in the times of banking apps.

This also captures people without a GEWISDB registration, those similarly should not be allowed a negative balance.

In the past a graduate has proposed allowing exceptions for graduates who sign a direct debit mandate indicating any negative balances may be charged to a specific bank account. It was decided not to do this at that point of time since it requires quite a bit of implementation and we did not have the time for that. (Although in the end we hope we would never need to use it because that will also be a bit of a hassle)

[rinkp]

If it turns out it is desirable to let graduates have a negative balance (since till now SudoSOS has allowed negative balances for most graduates), you can also let the BAC treasurer propose a change in terms of service which will allow them to have a negative balance. Or a change that allows the BAC to make exceptions and give some people access (although you probably want to establish criteria to prevent discussions on eligibility, but defining often at the social drink is a bit hard to measure)

[github-actions[bot]]

:tada: This issue has been resolved in version 0.1.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: