feature organizations

Prensentation

Add a way to create organizations in MONARC and integrate (merge) the back office with the MONARC software.

Rationale and Goals

The main goals are:

• to simplify the architecture of MONARC;

• to make MONARC more decentralized;

• to make future developments easier.

• MONARC architecture is currently quite complicated:

  • keep potential new contributors away;
  • complicated deployment (requires several servers) and updates;
  • the creation (thanks to ansible) of new clients (organizations) is also too complicated (requires a cron job, an Internet connection, new database for each client, a proxy alias for each client, etc.) and is slow;
  • the deletion (thanks to ansible) of clients is just partial;
  • this is costly to maintain and will slow our developments.

• an other goal is to have a more decentralized model (the back office is a central point):

  • (public) risk models should be shareable (and exportable/importable) between organizations. This would be easy for a specific MONARC instance. Also this would be doable between MONARC instances via an API (with some development efforts).

• the back office is a failure point. Models are directly provided by the database of the server, without a proper API. If the back office is down (or just the database service) some functionalities (like the creation of an analysis) of the front offices are blocked;

• when switching from Angular to Vue.js 3 it will be a waste of time to rewrite views from the back office that are already present in MONARC (because views to manage the servers and the clients could simply be deleted)

Specifications

Database model

Organization

An organization is basically composed of users. These users can share different risk analysis with different levels of permission.

An organization would benefit from MONARC common models, but also will be able to use custom models.

The administrator of an organization will be able to manage:

• the organization name;
• the organization custom logo;
• custom templates for the deliveries.

A user can be the member of several organizations.

Actually a Client object in the back office is defined by the following attributes:

• id
• model_id
• server_id
• logo_id
• name
• proxyAlias
• contact_email
• first_user_firstname
• first_user_lastname
• first_user_email
• creator
• createdAt
• updater
• updatedAt

We should merge Client object in the new Organization object defined with the following attributes:

• id
• name
• logo_id
• templates
• users
• anrs
• models (previously model_id, we now have a list of models available for an organization)
• first_user_firstname
• first_user_lastname
• first_user_email
• creator
• createdAt
• updater
• updatedAt

proxyAlias and server_id attributes are now useless.

Below, the corresponding diagram:

We should consider to replace first_user_firstname, first_user_lastname and first_user_email by a relation to a User object. The downside is that this contact user should of course be present in the database.

Models

A model could have:

• an owner;
• a visibility attribute (public/private);

It could be possible to copy a (public) model.

User interfaces

Directly impacted user interfaces

• knowledge base view (already present in MONARC FO);
• organization administration view (new view);

The views to manage servers and the clients are now useless.

Migration

Former clients will become the new MONARC organizations.
For current MONARC installations with a back office, this means that each client on the different FO servers will be migrated as an Organization in a single MONARC instance.