Philosophy & Architecture

Abstract Information Management and Authority Service (aimaas)

Philosophy

Are you familiar with PIM systems for eCommerce? They are central hubs for product information and related media. They can be the primary authority for this information or an intermediary between systems providing the data (e.g. a company's internal system) and systems consuming the data (e.g. a web-shop on the internet).

With aimaas we want pick up this solution and transform it into an abstract and general-purpose solution. With such an abstract foundation we want to cover as many simple use cases as possible so that we only need to create additional modules for highly specialized use cases.

aimaas wants to allow users to define their own object types with different attributes and value types such that every change is traceable and reviewable. In addition we want it to make easy to access aimaas via an API.

The gap to fill

There are already several tools out there serving very similar purposes. The closest candidate is PostgREST. It would fulfill all our needs for the use cases described below with a few exceptions/caveats:

• It does not allow the desired tracking of changes and review process out of the box.
• Instead of imposing a schema on a EAV data model one can just define the desired data model, but to do so would require permissions on the DB and knowledge of SQL.

Instead we would like to provide an easy to use (and intuitive) application to users.

Architecture

Data model

The Value table in the diagram represents a set of tables; one for each data type (e.g. integers, floats, foreign key, ...)

In a typical CRUD approach the update operation writes changes directly to the target database table and field. In aimaas we want to be able to deviate from this approach and review changed data before it is actually written to its destination:

Requirements

1. Starting from a typical EAV model aimaas must extend the structure to include multiple schemas allowing entities to have different attribute sets.
2. Similar to database tables the schema must define ...
   1. whether attributes are required.
   2. whether attributes have unique values.
3. aimaas must keep track of changes.
   1. Changes to fields of Entity, Value and AttributeDefinition must be tracked.
4. aimaas must offer the possibility to review changes before they are written to the target.
   1. It must be possible to enable the review feature on the schema level.
   2. When the feature is enabled:
      1. A value must not be changed until the review is accepted.
      2. Aimaas must warn about pending changes/reviews when an entity is being edited.
5. create, update and delete operations should be encapsulated using database transactions and locks.

Server - Client

aimaas is considered a place where humans and machines exchange data. Therefore, we choose a server - client architecture:

Backend

The backend of aimaas is the generic service holding data. It's primary purpose is to provide access to data for other systems as well as humans.

Requirements

1. The backend should connect to a PostgreSQL database.
2. The backend must be written in Python.
3. The backend should be implemented with a major framework (e.g. Django, Fast API, Flask).
4. The backend must provide an API (CRUD).
5. The API must dynamically adapt to changes to schemas and allow filtering.
6. The API must provide a dynamically created documentation, which reflects the schema-dependent fields and filters.
7. The backend should not render HTML templates except for the frontend client.
8. Entities must not be deleted from the database. They must be marked as deleted instead.

Authentication & Authorization

aimaas needs to authenticate users and manage permissions.

Requirements

1. The backend must ensure authentication.
2. The backend must enforce permissions.
   1. Permissions must be pre-defined for entities and schemas.
   2. Permissions must be additive/hereditary, e.g.
      • a user can have permission to add/update entities for schema X, but only permission to update a specific entity for schema Y.
      • A permission granted on the schema cannot be revoked on the entity level.
      • A permission granted to a group cannot be revoked for a member of this group.
   3. It must be possible to create and delete groups.
   4. It must be possible to add users to and remove users from groups.
   5. It must be possible to add groups to and remove groups from groups.
   6. It must be possible to grant permissions to and remove permissions from users and groups.
   7. Users without permission to change/update an entity may request a change, but not review (i.e. accept/reject) it.

Frontend

The frontend is the primary interface for interaction with humans. It is a client for the API provided by the backend.

Requirements

1. The frontend must be a web application written in HTML, CSS and Javascript.
2. The frontend should be implemented with a major framework (e.g. Vue.js, Angular, React).
3. The frontend must contain a generic mode, which allows:
   1. Switching between schemas.
   2. Showing a list of entities (with primary attributes) and single entities (with all attributes).
   3. Editing entities and schemas.
   4. Approving/Rejecting changes.
   5. Granting/Revoking of permissions.
   6. Managing of groups (i.e. create, delete, add user, add subgroup...).
4. The frontend must allow to be extended with usecase-specific modes (e.g. showing a table with product LCM dates and a graph of module dependencies).
5. The frontend should be designed with the SUSE Product Brand.

Environment

The application should be written with container-technology in mind.

Requirements

1. The application can be built as container image or Python package.
2. The application should be configurable via environment variables.

Use Cases

Despite it's abstract and generic nature, there are already use cases for which aimaas will be needed.

Product information

• Generic data: Name, Type, CPE, LCM Status, ...
• LCM dates: First release, End of Life, ...

Product module relations

The relations (not only dependencies) between products and available modules or extensions are important during automated testing of modularized products. Besides the most important relation (module X requires module Y), other relation information (e.g. module X cannot be installed together with module Z) is also very important:

Minimal viable product

The above requirements describe the abstract, feature-complete core application. The minimal viable product must contain the following features:

• Create schema with attribute definitions.
• Create, list, update entities and attributes.
• Authentication of users (no groups, permissions).

The minimal viable product must allow to create the schemas and entities for the use cases described above.