oms-core-elixir

The elixir implementation serves as a maybe temporary, maybe permanent drop in for oms-core written in laravel until that one is production ready. This is because I (Nico) want the system to go online at some point but don't like php. 

I had some further thoughts, especially did I design the permission system more in detail as that was what failed the previous core development effort by Derk.

Bodies

Bodies are legislative parts of the association and can be joined through join-requests. 

Circles

Circles are basically a group of members. Circles grant attached and inherited permissions to a user. There can be bound and free circles, depending whether they are part of a body or not. It is not possible to change a bound circle into a free one and vice versa. Also a body can define a shadow circle which will be automatically joined upon joining the body. A bound circle can only be joined by members of the body.

Circles that are joinable can freely be joined, as long as the body-membership constraint on bound circles is fulfilled. Non-joinable circles can only obtain members by someone adding them forcefully (still respecting the body-membership constraint). If a circle is non-joinable, also all of its children need to be non-joinable. A joinable parent can however have both types of children.

Permission system

The permission system is described more in detail here

User-Member duality

Because I moved out login and signout based concerns into a seperate microservice, the login microservice, there is a one-to-one relation between the table users and the table members, whereas a user does not necessarily need to have a member. This has mainly technical reasons because I am crazy for splitting everything and also because I developped loginservice before oms-core-elixir to also be used standalone. This has the disadvantage of sync need between oms-core-elixir and loginservice on member creation and deletion

Recruitment campaigns

Member accounts can be created in two ways, either by manually adding them as member of a body or by them signing up through a recruitment campaign. A recruitment campaign can, if set, autoactivate the user account or leave that to an admin. Also it can automatically create a join request to a fixed body. This way, admins of the body could activate the account after approving the join request.