TIDO merge requestshttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests2021-05-17T10:20:55Zhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/158style: adjust padding in tree view2021-05-17T10:20:55ZNils Windischstyle: adjust padding in tree viewadding missing padding right and adjust general padding; saves space.
closes #255adding missing padding right and adjust general padding; saves space.
closes #255Nils WindischNils Windischhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/156style: consistent border radius for hover items and alike2021-05-12T07:16:56ZNils Windischstyle: consistent border radius for hover items and alike# Feature
## Summary
consistent border radius for hover items and alike
## Tests
Are we able to test this new feature?
* [x] Yes, you can test by following these steps: …
panel toggle buttons and items in the tree do have a border-...# Feature
## Summary
consistent border radius for hover items and alike
## Tests
Are we able to test this new feature?
* [x] Yes, you can test by following these steps: …
panel toggle buttons and items in the tree do have a border-radius of 3 now
## Related Tickets
closes #247Nils WindischNils Windischhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/155style: make tabs in various panel look the same2021-05-11T10:44:19ZNils Windischstyle: make tabs in various panel look the sameNils WindischNils Windischhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/151style: panel title style polishing2021-05-05T13:21:01ZNils Windischstyle: panel title style polishing# Feature
## Summary
new styling of panel titles
## Does the result of the MR comply to our "definition of done"?
* [ ] Acceptance criteria met
## Tests
Are we able to test this new feature?
* [x] Yes, you can test by following th...# Feature
## Summary
new styling of panel titles
## Does the result of the MR comply to our "definition of done"?
* [ ] Acceptance criteria met
## Tests
Are we able to test this new feature?
* [x] Yes, you can test by following these steps: …
can you still make out panel title as panel titles?
Is the code valid/functional? It's not about if you like it visually.
## Changelog
* [ ] I added a statement to the CHANGELOG.
## Related Tickets
### Closes
#243Nils WindischNils Windischhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/150style: style links in metadata and similar places2021-05-05T03:54:31ZNils Windischstyle: style links in metadata and similar places# Feature
## Summary
make links less ugly.
## Tests
* [x] Yes, you can test by following these steps: …
Entrypoint https://ahikar-dev.sub.uni-goettingen.de/api/textapi/ahikar/arabic-karshuni/collection.json
Just have a look at metad...# Feature
## Summary
make links less ugly.
## Tests
* [x] Yes, you can test by following these steps: …
Entrypoint https://ahikar-dev.sub.uni-goettingen.de/api/textapi/ahikar/arabic-karshuni/collection.json
Just have a look at metadate where links are present, are they not blu and underlined anymore, but have a grey background and get white on blue if hover
/cc [Mathias Göbel](https://gitlab.gwdg.de/mgoebel), [Frank Schneider](https://gitlab.gwdg.de/schneider210), [Michelle Weidling](https://gitlab.gwdg.de/mrodzis)Nils WindischNils Windischhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/149style: don't use CSS style2021-04-30T06:47:37ZNils Windischstyle: don't use CSS style# Feature
## Summary
use CSS style block instead of style="asdf"
## Does the result of the MR comply to our "definition of done"?
* [ ] Code reviewed
* [ ] Non-Functional requirements met
## Tests
Are we able to test this new featu...# Feature
## Summary
use CSS style block instead of style="asdf"
## Does the result of the MR comply to our "definition of done"?
* [ ] Code reviewed
* [ ] Non-Functional requirements met
## Tests
Are we able to test this new feature?
* [ ] Yes, you can test by following these steps: does it still look like before, but the button text (prev/next) is 14px instead of 16px?Nils WindischNils Windischhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/147style: reposition icons in header2021-04-29T11:21:56ZNils Windischstyle: reposition icons in headerrelated to #215related to #215Nils WindischNils Windischhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/146style: adjust icon colors in header2021-04-29T09:13:36ZNils Windischstyle: adjust icon colors in headerchoose whatever entrypoint you like…
language, info and color scheme icons should be blue (primary). dark mode is tested as well.choose whatever entrypoint you like…
language, info and color scheme icons should be blue (primary). dark mode is tested as well.Mathias GoebelMichelle Weidlingschneider210dindigalaMathias Goebelhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/137Support/svg icons2021-04-23T09:36:48Zschneider210Support/svg icons# Feature
## Summary
This MR provides SVG icons for the text entities, css classes for the (text) highlighting and refactoring addressing perfomance issues
## Does the result of the MR comply to our "definition of done"?
* [ ] Unit t...# Feature
## Summary
This MR provides SVG icons for the text entities, css classes for the (text) highlighting and refactoring addressing perfomance issues
## Does the result of the MR comply to our "definition of done"?
* [ ] Unit tests passed
* [x] Code reviewed
* [ ] Acceptance criteria met
* [ ] Functional tests passed
* [ ] Non-Functional requirements met
* [x] Product Owner accepts the User Story
## Documentation
* [x] I updated the README (if applicable)
* [ ] I provided my functions with appropriate documentation
* [ ] I adjusted other parts of the documentation (if applicable)
## Tests
Are we able to test this new feature?
* [ ] Yes, everything can be done via unit tests.
* [ ] Yes, you can test by following these steps: …
* [ ] No, it is not possible.
## Changelog
* [ ] I added a statement to the CHANGELOG.
## Related Tickets
Add all related issues and especially those to be closed.
### Related
### Closes
## Logs and Screenshots
/cc [Mathias Göbel](https://gitlab.gwdg.de/mgoebel), [Frank Schneider](https://gitlab.gwdg.de/schneider210), [Michelle Weidling](https://gitlab.gwdg.de/mrodzis)schneider210schneider210https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/134save space wherever possible2021-04-23T07:52:20ZNils Windischsave space wherever possibleKristine VoigtdindigalaKristine Voigthttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/132feat: annotations2021-04-26T09:06:18Zschneider210feat: annotations# Feature
## Summary
This MR enables TIDO to display annotations.
## Does the result of the MR comply to our "definition of done"?
* [ ] Unit tests passed
* [ ] Code reviewed
* [ ] Acceptance criteria met
* [ ] Functional tests passe...# Feature
## Summary
This MR enables TIDO to display annotations.
## Does the result of the MR comply to our "definition of done"?
* [ ] Unit tests passed
* [ ] Code reviewed
* [ ] Acceptance criteria met
* [ ] Functional tests passed
* [ ] Non-Functional requirements met
* [x] Product Owner accepts the User Story
## Documentation
* [x] I updated the README (if applicable)
* [x] I provided my functions with appropriate documentation
* [ ] I adjusted other parts of the documentation (if applicable)
## Tests
Are we able to test this new feature?
* [ ] Yes, everything can be done via unit tests.
* [x] Yes, you can test by following these steps:
**prerequisites**:
- checkout the branch: `git checkout feature/#41-annotations`
- update your local modules once: `npm i`
- open the **index.template.html** file:
- set an entrypoint: **https://ahikar-dev.sub.uni-goettingen.de/api/textapi/ahikar/arabic-karshuni/collection.json**
- start your dev environment: `npm run dev`
**feature tests**:
- **action**
- navigate to **Cod. Arab. 236 Copenhagen => Sheet 2a**
- **expectation**
- data toggles in the anno panel are selected (according to the content types available in the text)
- the list below shows all the annotations highlighted
- the text counterparts are underlined and have an icon attached to it (according to the type given)
- **action**
- click on the names toggle at the top
- **expectation**
- names toggle turns inactive
- the list gets reduced by all the annotations that correspond to names
- text counterparts (names) aren't underlined and haven't an icon attached to it
- **action**
- click on the names toggle at the top again
- **expectation**
- pls refer to the step above; this time the behaviour is the other way around: toggle gets active, names are back in list (in sorted order, taking the remaining / shown data types into account) and text is highlighted again
- **action**
- click a single annotation in the annotation list
- **expectation**
- the item gets dehighlighted as it's text counterpart in the text panel does and the "none" button is highlighted, since now there aren't all of the annotations selected
- **action**
- reverse the last step: click the dehighlighted text entity in the in the text panel
- **expectation**
- the text gets highlighted again as it's list counterpart in the annotation panel does and the "all" button is highlighted again (pls take a look at the lower third of the anno panel => options)
- **action**
- click on **none** in the "options section" (see above)
- **expectation**
- all the annotations get dehighlighted at once but are still shown. this applies to the text entities as well
- **action**
- hover over the comment toggle
- **expectation**
- since the current item doesn't contain any comment, the cursor turns into a "disabled state" and the toggle isn't clickable
- **action**
- click all active data type toggles one after another
- **expectation**
- the toggles turn inactive
- all the text entities get dehighlighted
- there is no list of annotations in the anno panel anymore
- instead there is a notification that addresses the user to interact: **Toggle at least one data type to show annotations**
- **action**
- from here (referring to the last step) click an arbitray text entity in the text panel
- **expectation**
- the appropriate text entity gets highlighted (underlined and icon attached)
- the data type toggle gets active (according to the type you clicked on) and every corrseponding type is shown
- only the annotation that matches it's text counterpart is highlighted. All the others are shown, but are dehighlighted
- **action**
- select the "next" item: e.g. click on **next sheet** or select it in the tree => **Sheet 2b**
- **expectation**
- this item doesn't contain any annotation at all, hence a user notification is displayed: => **no annotations available**
- **action**
- navigate to **Sheet 4a**
- **expectation**
- the annotations get updated according to the current item shown
- the places toggle gets inactive (no places here)
- the comments toggle turns active (the item contains a single comment)
- **action**
- click the names toggle
- **expectation**
- the annotation list shows only the single comment
- since there is a single item in the annotation list only, the sorting buttons completely disappear
**Different text types**
- **action**
- navigate to **Mingana Syriac 133 ff.82v-103r => Sheet 82a**
- click on **TRANSLITERATION** at the top of the text panel to switch the text
- **expectation**
- the annotations update according to the text type selected
**Configuration**
**Pls note**: (just as a reminder) since it's about config, you have to reload your page everytime you are about change sth in the **index.template.html** file
- **action**
- open the **index-template.html** file
- find the section for the **annotations** to be configured (at the top of the config object)
- toggle the **show** key to `false` and reload your page
- **expectation**
- all the data type toggles are inactive
- a user notification shows up
- nothing is highlighted
- **action**
- change an icon (**config => types**): e.g. for the persons:
`"css": "fa-user"` => `"css": "fa-search"`
`"icon": "fasUser"` => `"icon": "fasSearch"`
refresh your page
- **expectation**
- all the icons (according to the data type you changed) change to the newly configured icon face
- **action**
- repeat the last step, but this time provide a nonsense name for the SVG, or rather force a typo: e.g.
`"icon": "fasUser"` => `"icon": "fasBla"`
- **expectation**
- since **fasBla** doesn't exist, a fallback icon is shown in the annotation panel (data toggles and list alike). For the time being this fallback point to **fasTimes**, but this might need an improvement from a semantical perspective
- **action**
- change a label: e.g. **"label": "Places"** to **"label": "Orte"**
- **expectation**
- the label of the appropriate data type toggle (top of the anno panel) changes according to your configuration
- **action**
- **add** a completely new **object** to the **types array**:
`
{
"content-type": "TestIt",
"css": "fa-search",
"icon": "fasSearch",
"label": "ABC123"
},
`
- **expectation**
- your recently created additional content type gets rendered as an additional data type toggle.
**Pls note**: As long as the API doesn't provide a type called **TestIt** and / or the current item you are displaying doesn't contain an equaling content type, the data toggle is disabled
Please take a look at the [README section](https://gitlab.gwdg.de/subugoe/emo/Qviewer/-/blob/feature/%2341-annotations/README.md#the-keys-in-detail) as well. Thank you!
* [ ] No, it is not possible.
## Changelog
* [ ] I added a statement to the CHANGELOG.
## Related Tickets
Add all related issues and especially those to be closed.
### Related
#41
#158
#159
#161
#162
#169
#170
#179
#180
#190
#225
### Closes
Closes
#41
#158
#159
#161
#162
#169
#170
#179
#180
#190
#225
## Logs and Screenshots
/cc [Mathias Göbel](https://gitlab.gwdg.de/mgoebel), [Frank Schneider](https://gitlab.gwdg.de/schneider210), [Michelle Weidling](https://gitlab.gwdg.de/mrodzis)schneider210schneider210https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/130feat: configure to show either of the panel toggles2021-04-22T12:28:29Zschneider210feat: configure to show either of the panel toggles# Feature
## Summary
This MR provides the option to configure either of the toggles. e.g. making a panel toggable
## Does the result of the MR comply to our "definition of done"?
* [ ] Unit tests passed
* [x] Code reviewed
* [ ] Acce...# Feature
## Summary
This MR provides the option to configure either of the toggles. e.g. making a panel toggable
## Does the result of the MR comply to our "definition of done"?
* [ ] Unit tests passed
* [x] Code reviewed
* [ ] Acceptance criteria met
* [ ] Functional tests passed
* [ ] Non-Functional requirements met
* [x] Product Owner accepts the User Story
## Documentation
* [x] I updated the README (if applicable)
* [ ] I provided my functions with appropriate documentation
* [ ] I adjusted other parts of the documentation (if applicable)
## Tests
Are we able to test this new feature?
* [ ] Yes, everything can be done via unit tests.
* [x] Yes, you can test by following these steps:
- checkout the branch: `git checkout feature/#191-configure-panel-toggles`
- update your local modules once: `npm i`
- open the **index.template.html** file:
- set an entrypoint: **https://ahikar-dev.sub.uni-goettingen.de/api/textapi/ahikar/arabic-karshuni/collection.json**
- switch any of the **toggle**s in the **panels array** to `false` or the other way around
- start your dev environment: `npm run dev` and watch the toggles in the header bar dis/appear.
**Note**: pls keep in mind - since it's about config and you want to chnage it several times -, TiDO has to be reloaded, everytime you change the config.
* [ ] No, it is not possible.
## Changelog
* [ ] I added a statement to the CHANGELOG.
## Related Tickets
Add all related issues and especially those to be closed.
### Related
### Closes
"${191}"
## Logs and Screenshots
/cc [Mathias Göbel](https://gitlab.gwdg.de/mgoebel), [Frank Schneider](https://gitlab.gwdg.de/schneider210), [Michelle Weidling](https://gitlab.gwdg.de/mrodzis)schneider210schneider210https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/125style: consistify styling2021-03-23T09:45:09ZNils Windischstyle: consistify stylingpadding and alike in tree view and metadata panelpadding and alike in tree view and metadata panelschneider210dindigalaschneider210https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/122style: style annotations panel details2021-03-17T12:52:05ZNils Windischstyle: style annotations panel detailsschneider210schneider210https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/121style: un-hide scroll bar in text panel2021-03-12T10:04:45ZNils Windischstyle: un-hide scroll bar in text panelschneider210dindigalaschneider210https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/116feat: adjust content type/s according to the recently introduced content key ...2021-03-05T09:02:20Zschneider210feat: adjust content type/s according to the recently introduced content key from the API# Feature
## Summary
This MR provides the **adjusted content object according to the API specs for TIDO**
It serves as a **prerequisite** for [Enable TIDO to display more (+n) text types as tabs](https://gitlab.gwdg.de/subugoe/emo/Qv...# Feature
## Summary
This MR provides the **adjusted content object according to the API specs for TIDO**
It serves as a **prerequisite** for [Enable TIDO to display more (+n) text types as tabs](https://gitlab.gwdg.de/subugoe/emo/Qviewer/-/issues/165) and ensures (so far), that the content resource is fetched and displayed as ususal in the text panel although the (content) data has changed.
What have I done?
- **adjust datatype**:
the formerly contenturl which used to be a string now becomes an array of an arbitrary number of objects; each holding a url and a mime-time with an optional sybtype, whereas the latter isn't taken into account *yet*.
- **provide new method getContent()**
since TIDO is supposed to display any type of html resource, the method checks the corresponding mime-types and - in case of matching - extracts the appropriate urls which in turn point to the according html resources
- **provide a (very basic) unit test**
it just ensures that the prop in the receiving component is present and is of type array
- **minor**:
additionally **rename the css class** *rtl-support* to *rtl* to match explicitely against it's config counterpart of the same name
*Pls note*:
this is sort of a collaboration between the back- and the frontend. both parties depend on each other. means: the changes haven't been merged in the backend, otherwise the Viewer would certainly break before this MR is merged.
**Hence**:
to build it, it has been necessary to have some sampledata to see it in action. so I had to use the entrypoint of the karshuni collection on the **test-server**. Pls see below's instructions on how to verify it.
## Does the result of the MR comply to our "definition of done"?
* [x] Unit tests passed
* [ ] Code reviewed
* [ ] Acceptance criteria met
* [ ] Functional tests passed
* [ ] Non-Functional requirements met
* [x] Product Owner accepts the User Story
## Documentation
* [ ] I updated the README (if applicable)
* [x] I provided my functions with appropriate documentation
* [ ] I adjusted other parts of the documentation (if applicable)
## Tests
Are we able to test this new feature?
* [ ] Yes, everything can be done via unit tests.
* [x] Yes, you can test by following these steps:
- check out the branch:
`git checkout feature/#151-api-content-key`
- change the entrypoint in the `index.template.html` file to:
`https://ahikar-test.sub.uni-goettingen.de/api/textapi/ahikar/arabic-karshuni/collection.json`
- watch the content resource still to be displayed inside the text panel as usual
* [ ] No, it is not possible.
## Changelog
* [ ] I added a statement to the CHANGELOG.
No, it will be done automatically by `npm write-changelog` at the end of the actual sprint.
## Related Tickets
Add all related issues and especially those to be closed.
### Related
Related "${165}"
### Closes
Closes #151
## Logs and Screenshots
/cc [Mathias Göbel](https://gitlab.gwdg.de/mgoebel), [Frank Schneider](https://gitlab.gwdg.de/schneider210), [Michelle Weidling](https://gitlab.gwdg.de/mrodzis)schneider210schneider210https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/115Feature/#138 metadata generic textapi2021-02-23T15:51:51Zschneider210Feature/#138 metadata generic textapi# Feature
## Summary
This MR provides extended sections of the metadata on each level (Collection, Manifest, Item).
It also takes care of the project specific metadata object optionally given in the manifest object.
All the item data...# Feature
## Summary
This MR provides extended sections of the metadata on each level (Collection, Manifest, Item).
It also takes care of the project specific metadata object optionally given in the manifest object.
All the item data is passed down now to the metadata component as opposed to before, where just certain fields have been extracted.
The image license and corresponding notes are displayed now as well.
## Does the result of the MR comply to our "definition of done"?
* [ ] Unit tests passed
* [ ] Code reviewed
* [ ] Acceptance criteria met
* [ ] Functional tests passed
* [ ] Non-Functional requirements met
* [x] Product Owner accepts the User Story
## Documentation
* [x] I updated the README (if applicable)
* [ ] I provided my functions with appropriate documentation
* [ ] I adjusted other parts of the documentation (if applicable)
## Tests
Are we able to test this new feature?
* [ ] Yes, everything can be done via unit tests.
* [x] Yes, you can test by following these steps:
switch the entrypoints:
- ahikar collection: "https://ahikar-dev.sub.uni-goettingen.de/api/textapi/ahikar/arabic-karshuni/collection.json"
- ahikar manifest: "https://ahikar-dev.sub.uni-goettingen.de/api/textapi/ahikar/arabic-karshuni/3r177/manifest.json"
- sampledata: https://subugoe.pages.gwdg.de/emo/backend/sampledata/collection.json
and take a look at the metadata panel
* [ ] No, it is not possible.
## Changelog
* [ ] I added a statement to the CHANGELOG.
## Related Tickets
Add all related issues and especially those to be closed.
### Related
### Closes
Closes #${138}
## Logs and Screenshots
/cc [Mathias Göbel](https://gitlab.gwdg.de/mgoebel), [Frank Schneider](https://gitlab.gwdg.de/schneider210), [Michelle Weidling](https://gitlab.gwdg.de/mrodzis)schneider210schneider210https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/113ci: fix typo2021-01-21T10:27:46ZMichelle Weidlingci: fix typoAs a result of !112 the pipelines failed because of a typo in the CI config.As a result of !112 the pipelines failed because of a typo in the CI config.Ahikar Version 0.15.0Michelle Weidlingschneider210Michelle Weidlinghttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/112fix: patch the entrypoint for the Ahikar demo / dev branch2021-01-21T10:24:08Zschneider210fix: patch the entrypoint for the Ahikar demo / dev branch# Bug fix
## Summary
Apart from what is mentioned in the main ticket you are going to close with this
MR, tell us what you have done to achieve this goal.
### add a shell script (set_entrypoint_ci.sh)
to patch the entrypoint
**reason...# Bug fix
## Summary
Apart from what is mentioned in the main ticket you are going to close with this
MR, tell us what you have done to achieve this goal.
### add a shell script (set_entrypoint_ci.sh)
to patch the entrypoint
**reason**:
if an entrypoint is provided, it will be compiled and integrated into the build.
the build takes precedence and prevents the according config option to take effect (in index.html)
on the the other hand, the entrypoint is needed for the Ahikar demo page to show any data
[Ahikar Demo actually not working without entrypoint](https://subugoe.pages.gwdg.de/emo/Qviewer/develop/#/)
hence the script has to be run once everytime a merge into dev is done and therefore it has to be integrated into **.gitlab-ci.yml**
this assures to keep the demo page running / showing the Ahikar collection data on the one hand side and to avoid further config conflicts on the other.
## Does the result of the MR comply to our "definition of done"?
* [ ] Unit tests passed
* [ ] Code reviewed
* [ ] Acceptance criteria met
* [ ] Functional tests passed
* [ ] Non-Functional requirements met
* [x] Product Owner accepts the User Story
### Related
### Closes
## Changelog
* [ ] I added a statement to the CHANGELOG.
No.
## Documentation
* [ ] I updated the README (if applicable)
* [ ] I provided my functions with appropriate documentation
/cc [Mathias Göbel](https://gitlab.gwdg.de/mgoebel), [Frank Schneider](https://gitlab.gwdg.de/schneider210), [Michelle Weidling](https://gitlab.gwdg.de/mrodzis)Ahikar Version 0.15.0Michelle Weidlingschneider210Michelle Weidlinghttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/111fix: display meta items only if provided by the api2021-01-15T16:35:15Zschneider210fix: display meta items only if provided by the api# Bug fix
## Summary
Apart from what is mentioned in the main ticket you are going to close with this
MR, tell us what you have done to achieve this goal.
- The meta data are now displayed on a *provided* basis only, e.g.: if any data...# Bug fix
## Summary
Apart from what is mentioned in the main ticket you are going to close with this
MR, tell us what you have done to achieve this goal.
- The meta data are now displayed on a *provided* basis only, e.g.: if any data isn't delivered by the API, the corresponding item doesn't get rendered
- provided a type check for the editor field which made the meta data crash
*Note:* to check it, pls check out the branch *bugfix/metadata* and watch the metadata panel once with the usual Ahiqar endpoint (default) and change that entrypoint to *https://subugoe.pages.gwdg.de/emo/backend/sampledata/collection.json* and refresh your page hereafter to take another look at the metadata panel once again.
## Does the result of the MR comply to our "definition of done"?
* [ ] Unit tests passed
* [ ] Code reviewed
* [ ] Acceptance criteria met
* [ ] Functional tests passed
* [ ] Non-Functional requirements met
* [x] Product Owner accepts the User Story
### Related
### Closes
## Changelog
* [ ] I added a statement to the CHANGELOG.
No, it will be done automagically.
## Documentation
* [ ] I updated the README (if applicable)
* [ ] I provided my functions with appropriate documentation
/cc [Mathias Göbel](https://gitlab.gwdg.de/mgoebel), [Michelle Weidling](https://gitlab.gwdg.de/mrodzis)schneider210schneider210