# Functional Data Model

![Functional Data Model](./functional_data_model.svg)

The `TaskTemplate` defines a type of task to be executed. An instance
o a `TaskTemplate` is a `Task` and it will be executed by a `User`.
A `Task` may contain `SubTask`s (Punkte). Each `Task` and – if
configured – each `Subtask` will eventually have a `Result`
attached, where a `Result` contains values entered by a `User` and
additionally can contain a collection of `Comment`s, `Picture`s and
`AuditLogs`. When a `Result` is attached to a `Task` or `Subtask` it can
create a follow up `Task` if that is configured in the `TaskTemplate`
(Weiterleitung).

A `Report` is configured to show `Result`s for several `Task`s based on
a `Template`, and at the same time refers to a `Folder`, because the
Folder structure is also used to group different `Report`s and give them
a name. Which actual `Result`s and with that implicitly which executed
`Task`s go into the generation of a `Report` depends on the time frame
selected by a `User` when issuing a `Report`.

A `Department` describes a physical location. It can contain an
arbitrary amount of `Folder`s recursively, where a `Folder` is just a
named tree node to structure a department by names. A `TaskTemplate` and
`ReportTemplate` are always assigned to a `Folder` to describe where its
instances take place.

![Functional Data Model](./functional_data_model_rights.svg)


A `UserGroup` bundles many `User`s, while still a `User` can
belong to many `UserGroup`s where one of them is his designated
main group. A `Usergroup` belongs to a single department
and – unlike folders – cannot contain more `UserGroup`
recursively. In order to keep the number of arrows in the graph small,
arrows that are the same for `User` and `UserGroup` are drawn only
to/from the `UserRelated` package.

A `Permission` is a single right to do something. There is a finit
static set of these `Permission`s defined in the system. A `User` has
a set of these flags, which define what actions he is allowed to do in
principal. The `Permission`s consists of five static access rights, that
are uses in several places to decide, e.g., if a `User` can see a task,
a report, a folder and so on. The `Permission`s furthermore consist of
additional 16 static rights to allow specific actions in the UI, like
editing/deleting specific things, or view or configure something.

The `Permission`s do not only appear on a `User` to signal that he has a
certain right, but rather also on different `Template`s and `Folder`s to
specify what a right a `User` needs to have in order to access it.

# Technical Data Model

![Technical Data Model](./technical_data_model.svg)

A `TaskTemplate` is stored in `MBD_AGB`. Technically the `Task` instance
of a `TaskTemplate` is only modelled implicitly: For every execution
of a `Task` a `Result` is written to `MBD_ERG` and refers to the
`TaskTemplate` it was based on. The mere existence of such an entry is
the representation of an `Task`. `Picture`s, `Comment`s and `AuditLog`s
live into the respective `MDB_PIC`, `MBD_SAK`, `MBD_AUD`.

`Report` definition is stored in `MBD_QAG`, and is basically just a
cross-table between `MBD_AGB` and `MBD_GRP`. By that it defines which
`Task`s' `Result`s can show up in a `Report` (depending on a selected
time frame) and also gives them a name by referring to a `Folder`.

A follow up `Task` for a `Result` is stored as an entry in `MBD_DYA` by
linking an entry in 'MBD_ERG' to another entry in `MBD_AGB`.

A `Result` is not only an entry in `MBD_ERG`, i.e., several entries are
written to several tables whenever a `User` completes a `Task`. First
data send for a `Task` are stored in `MBD_LOG` and get processed 1 to
1 to an entry in `JSON_RESULTS`. Additionally an entry is written to
`MBD_WEP`. `MBD_WEP` entries are used for Jasper reports, entries in
`JSON_RESULTS` for the other (which?) reports.

`Department`s are stored in `MBD_BER`.
`Folder`s are stored recursively in `MBD_GRP`.

`Permission`s are not stored in a separate table, rather they appear in
several tables as a single number, which is interpreted as a bit field
with a static mapping of bit position to a specific `Permission`. The
field name is usually suffixed by `_berechtigung`.

Additionally many tables contain one or more pairs of colums each
suffixed by `_recht_usg` and `_rechte_usr`. They contain a comma
separated list of foreign key ids that point to entries in `MBD_USR`
and `MBD_USG` respectively. The crosstables then may contain redundant
information to these columns.