Rasmus carried and pushed the idea, did (backend) design and development.
LHV Connect integration tested working, but that would mean developing our own accounting/billing completely.
Currently accounting managed through Merit. Still unsure if we want to continue. Looking at the API docs, I could see 20% of needed functionality there, but Erki-Lauri said you only need to provide a members list via API.
Connection to Merit API: Erki is giving conflicting information on the goal of the project.
No decision from board whether to go for full custom, or tie in to Merit + who is carrying the decision (+ agreement on work price).
Main business logic for the portal:
Member-based accounting/balance. Transaction history.
Single transactions (ex. vending machine, operating machines)
Subscriptions granting OIDC groups to user (including other users).
Balance + logic when to send e-mails, notifications and turn off the lights.
Metadata transactions / audit: subscription started/stopped, possibly door log / other usage
Comments visible to only management, 'what was the deal with them'.
Splitting it further to ledger and subscriptions doesn't seem reasonable, as it would be better for the views to be in the same place + development and integration is in the same place anyway.
Looking at alternatives, Lago and Lotus don't meet the requirements (not even 50%) and are paid.
Next up:
Linking members to packages
Rasmus carried and pushed the idea, did (backend) design and development.
- LHV Connect integration tested working, but that would mean developing our own accounting/billing completely.
- Currently accounting managed through Merit. Still unsure if we want to continue. Looking at the API docs, I could see 20% of needed functionality there, but Erki-Lauri said you only need to provide a members list via API.
- Connection to Merit API: Erki is giving conflicting information on the goal of the project.
- No decision from board whether to go for full custom, or tie in to Merit + who is carrying the decision (+ agreement on work price).
Main business logic for the portal:
- Member-based accounting/balance. Transaction history.
- Single transactions (ex. vending machine, operating machines)
- Subscriptions granting OIDC groups to user (including other users).
- Balance + logic when to send e-mails, notifications and turn off the lights.
- Metadata transactions / audit: subscription started/stopped, possibly door log / other usage
- Comments visible to only management, 'what was the deal with them'.
Splitting it further to ledger and subscriptions doesn't seem reasonable, as it would be better for the views to be in the same place + development and integration is in the same place anyway.
Looking at alternatives, Lago and Lotus don't meet the requirements (not even 50%) and are paid.
Next up:
- [ ] Linking members to packages
rasmus
changed title from Membership management portal to Membership management portal (CRM)2024-08-16 18:58:30 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Rasmus carried and pushed the idea, did (backend) design and development.
Main business logic for the portal:
Splitting it further to ledger and subscriptions doesn't seem reasonable, as it would be better for the views to be in the same place + development and integration is in the same place anyway.
Looking at alternatives, Lago and Lotus don't meet the requirements (not even 50%) and are paid.
Next up:
Membership management portalto Membership management portal (CRM)