The good, the bad and the ugly: oms-core-elixir

Let's sum up the good and the bad things about the core that is currently in use, to keep that in mind while developing the new one, so it'll be awesome from the start. Add your opinion here as well.

Sergey.

The good:

• the circles/permissions system

• postgres as the db

• the refresh/access token system

The bad:

• the stack (nobody knows elixir, you know)

• no gsuite integration

• users and members are separated, making it difficult to use

• no body history

• no actions history (like, there's no way to see who done what at which time. This can be solved by storing logs though)

• most fields are optional

• no consent in the db

• no automatic users management (like the users are not deleted from the body/suspended once the fee is expired)

• circles permissions (there's such thing as circle admin, when a person is a circle admin s/he can do more time, and it doesn't match the permissions schema)

• security-wise: no way to revoke a session (refresh_token); sessions are not revoked once the password is changed; no need to confirm email once it was changed; no notification on changed password

Proposals for the new core:

- js as a language

- postgres as a db

- Sails.js as a framework

- a lot of copypaste from statutory/events, most likely

- preserve the permissions/circles system exactly the way it is now (seems like a really flexible solution)

- merge users and members

- add the consent into the db

- disallow acting in any way if the optional fields are not set and if the consent is not given

- have background jobs to suspend/delete inactive users

Fabrizio.

The good:

• RBAC works well apparently (circles/permissions)

The bad:

• elixir

• no gsuite integration, which has led us to eventually waste a lot of time in manual creations.

• DB schema is not the most clever: users and members are separated entities, and that’s “logically” ok, but the email should be on the member (or anyway not where it is now)

• no body history, which was one top requirement

• no audit log (action history), which was one top requirement

• most fields are optional and not validated

• no consent in the db

• no cron/ automatic users management (like the users are not deleted from the body/suspended once the fee is expired)

• No LDAP, which was one top requirement

Proposals for the new core:

• js as a language

• postgres as a db for relational data, LDAP is also a first-class citizen. E.g. membership data in LDAP and only permission data on postgres (or, both membership and permission in postgres and ldap only membership)

• Strapi as a framework (see below why)

• maybe do not merge users and members if there is really no clever solution

• have background jobs to suspend/delete inactive users, to store statistics, etc (unless prom takes care of that / to make prom scrape it)

Why strapi:

• you define the model of the data through admin interface (or through code, but can check visually)

• allows postgres

• highly customisable, e.g. permission / hooks

• if not strapi, i think loopback.io would be better (sails has a lot of frontend in it, but we have ours; keystone looks less neat than loopback)

Proposal in general:

• introduce an API gateway layer, to incorporate common features there: authentication, authorisation, routes logging…

  • perhaps this can help when developing new modules (we used to have “oms-common-js”)

• remember to delegate authentication and security to auth0