TIDO merge requestshttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests2021-01-20T14:25:31Zhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/108Feature/#105 release via npm2021-01-20T14:25:31Zschneider210Feature/#105 release via npm# Feature
## Summary
The old MR has been closed due to the exposure of the AUTH_TOKEN.
Steps taken:
- [x] revoke old token in gitlab
- [x] create a new token with api access only
- [x] remove *.npmrc* from git index
- [x] add *.npmrc...# Feature
## Summary
The old MR has been closed due to the exposure of the AUTH_TOKEN.
Steps taken:
- [x] revoke old token in gitlab
- [x] create a new token with api access only
- [x] remove *.npmrc* from git index
- [x] add *.npmrc* to *.gitignore*
- [x] delete complete remote branch via web interface
- [x] clean up local references (`git remote prune origin`)
- [x] create a new topic branch
- [x] copy all changes from the old branch into the new topic one
This MR provides
- a tweaked build process to ease the integration of our product due to it's simplified build output.
The Viewer can be easily installed via npm and can be integrated with a single import statement.
- the means to easily release new versions of the Viewer by calling a run script.
- a configured webpack-object that refers to the build
- a shell script to tweak the quasar-build output (tweak_build.sh)
- an updated README file according to the recent changes
## 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)
## A short note on Licensing (everything is fine ;-) )
I got back to Hans-Werner Hilse and as a result, we can leave everything **as-is**. Since we didn't patch the Quasar or rather OSD code, we don't have to change anything and can stick to the AGPL.
## 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 for testing purposes
**Note**: If you don't already have a working Vue environment, simply set it up once; otherwise you can skip this step:
```bash
npm i -g @vue/cli @vue/cli-service-global
```
**scaffold** a test project (not refering to any branch at all; just *somewhere* on your machine)
```bash
vue create sample # just hit *enter* once to accept the defaults
```
The process might take some time ... it automatically creates a folder named according to the name you chose (**sample** in my case)
```bash
cd sample
```
Now you already have a basic, working Vue App.
## Installation
### 1A) setup npm config
since npm communicates with the package api, we have to setup a valid level entrypoint
**Registry setup**
The following command sets up an instance level entrypoint; sufficient for an installation only.
```bash
echo @subugoe:registry=https://gitlab.gwdg.de/api/v4/packages/npm/ >>.npmrc
```
**Note**: fire this command inside your recently created test folder (**sample**; see above => **prerequisites**)
### 1B) install the Viewer
```bash
npm i @subugoe/tido
```
## Integration
**edit** your **main.js** file located under **src/main.js**
and (for the sake of simplicity) **empty the file completely!**, and **replace** it's contents with that single line:
```bash
import '@subugoe/tido/dist/tido'
```
As a second step, **edit** your **index.html** file located inside the project's public folder (**public/index.html**)
**change** the following line
```html
<div id="app"></div>
```
to
```html
<div id="q-app"></div>
```
and finally **copy** our config object directly before the above mentioned div:
```html
<script id="tido-config" type="application/json">
{
"entrypoint": "https://subugoe.pages.gwdg.de/emo/backend/sampledata/collection.json",
"colors": {
"primary": "",
"secondary": "",
"accent": ""
},
"headers": {
"all": true,
"info": true,
"navigation": true,
"toggle": true
},
"labels": {
"item": "Sheet",
"manifest": "Manuscript"
},
"meta": {
"collection": {
"all": true,
"collector": true,
"description": true,
"title": true
},
"manifest": {
"all": true,
"creation": true,
"editor": true,
"label": true,
"location": true,
"origin": true
},
"item": {
"all": true,
"label": true,
"language": true
}
},
"standalone": true
}
</script>
```
### Run the Viewer
To test the integration, run:
```bash
npm run serve
```
and point your browser to: **http://localhost:8080** (or whatever port is addressed on your machine)
### Publishing
- 1) change the version of the viewer in the *package.json* file
(that's due to the fact, that a pkg with the same version can't be published twice; even if you unpublished it before)
- 2) setup npm config (project level entry and auth)
```bash
rm ~/.npmrc # just make sure to start the config from scratch
echo @subugoe:registry=https://gitlab.gwdg.de/api/v4/projects/10921/packages/npm/ >>.npmrc
npm config set '//gitlab.gwdg.de/api/v4/projects/10921/packages/npm/:_authToken' "$AUTH_TOKEN"
```
**replace** $AUTH_TOKEN with your Token ID
It's up to you, if you want to follow the process in single steps.
**if so**:
- a)
- `npm run build`
- `./tweak_build.sh` # assuming the script has eXecutable rights (`chmod u=rwx ./tweak_build.sh` otherwise)
- `npm publish --dry-run` (does exactly the same **publish** does, but without uploading the package)
**NOTE**:
if you leave the **dry option**, the package is published. so pls make sure to delete it again, after having proved it's successful upload, since it's about testing. you can find the result of your upload [here](https://gitlab.gwdg.de/subugoe/emo/Qviewer/-/packages)
**OR alternatively**
- b)
- run the (run-)script: `npm run release` which combines the three steps described above under **a)** (upload included)
* [ ] No, it is not possible.
## Changelog
* [x] I added a statement to the CHANGELOG.
No, because it will be done automatically.
## Related Tickets
[Issue #105](https://gitlab.gwdg.de/subugoe/emo/Qviewer/-/issues/105)
Add all related issues and especially those to be closed.
### Related
### Closes
[Issue #105](https://gitlab.gwdg.de/subugoe/emo/Qviewer/-/issues/105)
## 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)Ahikar Version 0.14.0Mathias Goebelschneider210Mathias Goebelhttps://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/109Feature/#113 easy configurability2021-01-27T14:32:50Zschneider210Feature/#113 easy configurability# Feature
## Summary
This MR provides provides the possibility to configure TIDO in one place (index.template.html), and a default view without annotations.
### config
**Before** (apart from the actual config in index.template.html):...# Feature
## Summary
This MR provides provides the possibility to configure TIDO in one place (index.template.html), and a default view without annotations.
### config
**Before** (apart from the actual config in index.template.html):
It has been necessary to configure the panels (show/hide, order, labels, unique id, connector) separately in `src/config/panels.js` aside the rest of the config.
This file held an array which had to be touched / changed to alter the panel behaviour and generated a random uniuqe id at runtime. (The latter is necessary to distinguish the panels from one another in regards to have dynamic components) and has (sort of) being exposed.
**Now**:
*panels.js* has been refactored and became a mixin (src/mixins/panels.js) without the panels array.
Instead the array moved into index.template.html and the unique id generation is treated separately apart from user's eyes, since it's just not a config option.
As a result, we don't have to point out to *not touch the id-key* (README.md) and have all of the viewer config gathered in one single place.
### default view
It also provides a default view with the annotations panel hidden, since it doesn't provide any content yet.
### tiny fix
Additionally it holds a small fix in the software info (src/components/softwareinfo.vue), which automatically fetches the actual year for the copyright info. (pls just tick the info button in the footer to see the actual year: => 2021)
## 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:
- check out the branch: `git checkout feature/#113-easy-configurability`
- update your local packages once: `npm i` (in the root dir of the project)
- start your local dev server: `npm run dev`
- edit the config file (**src/index.template.html**) as usual and watch the viewer change it's behaviour inside your browser (you might have to refresh your page)
**Pls Note**: it's not about new functionality but about the different implementation and therefore the possibility to configure our product in a single place.
Pls also make sure, to read the corresponding, updated part of our [README](https://gitlab.gwdg.de/subugoe/emo/Qviewer/-/blob/feature/%23113-easy-configurability/README.md#configure-the-panels)
* [ ] No, it is not possible.
## Changelog
* [ ] I added a statement to the CHANGELOG.
No. It will be done automatically.
## Related Tickets
Add all related issues and especially those to be closed.
### Related
[easy configurability](https://gitlab.gwdg.de/subugoe/emo/Qviewer/-/issues/113)
### Closes
[easy configurability](https://gitlab.gwdg.de/subugoe/emo/Qviewer/-/issues/113)
## 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)Ahikar Version 0.15.0schneider210dindigalaschneider210https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/204refactor: probit users selecting text in tree view2021-07-30T10:56:13ZNils Windischrefactor: probit users selecting text in tree viewtest it by trying to select the text of links (items) in the tree view. It shouldn't be possible anymore.
closes #320test it by trying to select the text of links (items) in the tree view. It shouldn't be possible anymore.
closes #320Ahikar Version 0.16.0Nils WindischNils Windischhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/229fix: dark mode contrast issues2021-10-08T08:37:32ZNils Windischfix: dark mode contrast issuesaffects the annotations panel only
Test it:
* switch your OS to dark mode
* see the floating action button adapt the right colors
* see the list of annotation adapt correct contrasted colors
Please note:
Text in the panel still looks o...affects the annotations panel only
Test it:
* switch your OS to dark mode
* see the floating action button adapt the right colors
* see the list of annotation adapt correct contrasted colors
Please note:
Text in the panel still looks off. This MR is not concerned with that, it's an issue with the support CSS.Nils WindischNils Windischhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/227make TIDO responsive again2021-10-07T08:39:02ZNils Windischmake TIDO responsive againrelated ticket #342
Test it:
* reduce the width of the viewport to <599px and watch the panels get stacked vertically
* reduce the width of the viewport to <599px and watch the header to get rearrangedrelated ticket #342
Test it:
* reduce the width of the viewport to <599px and watch the panels get stacked vertically
* reduce the width of the viewport to <599px and watch the header to get rearrangedNils WindischNils Windischhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/217make the theme switch configurable2021-08-31T09:52:50Zschneider210make the theme switch configurable# Feature
## Summary
This MR provides the option to configure the "theme switch / color palette" (whether to show it) and deletes the unicorn theme.
Since the unicorn stuff has been deleted, there are only two remaining "color themes"...# Feature
## Summary
This MR provides the option to configure the "theme switch / color palette" (whether to show it) and deletes the unicorn theme.
Since the unicorn stuff has been deleted, there are only two remaining "color themes": the **default** one configured in **quasar.conf.js** and - if a project decides to do so - the **projectcolors** configured in the **index.template.html** file.
If these projectcolors aren't set, it doesn't make sense at all to show the palette, since it would include the default theme only.
hence: in order to show the palette, a project has to
- a) set the **themes** switch to `true` **AND**
- b) configure their respective colors
## 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
* [ ] 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/#327-make-the-theme-switch-configurable`
- run your local env: `npm run dev`
## 1
- edit the **index.template.html** file:
- set **themes** to `true`
- configure some arbitrary colors: e.g.
```
"colors": {
"primary": "#E7E7E7",
"secondary": "#F9F711",
"accent": "#00CAD9"
}
```
**expected**: color palette shows up and you can switch between the two themes
## 2
- omit one of the two config steps described above, e.g.: stick to `themes: true` and delete the colors you set in the recent step
**expected**: color palette doesn't show up
## 3
- give it a try the other way around: set `themes: false` and reenter the colors you configured in step 1
**expected**: color palette doesn't show up
* [ ] 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
#327
## 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)schneider210dindigalaschneider210https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/215feat: implement config option for the language switch2021-08-26T10:05:35Zschneider210feat: implement config option for the language switch# Feature
## Summary
This MR provides the config option for the language toggle.
## Does the result of the MR comply to our "definition of done"?
* [ ] Unit tests passed
* [ ] Code reviewed
* [ ] Acceptance criteria met
* [ ] Functio...# Feature
## Summary
This MR provides the config option for the language toggle.
## 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:
- checkout the branch: `git checkout issue/make-language-switch-configurable` and start your local env
- open **index.template.html** and set `language-switch` to `false`
=> **expected**: the switch doesn't show up
* [ ] 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/212ahiqar-code-in-generic-tido2021-08-19T11:14:43Zschneider210ahiqar-code-in-generic-tido# Feature
## Summary
This MR provides the deletion of project specific code.
## Does the result of the MR comply to our "definition of done"?
* [ ] Unit tests passed
* [ ] Code reviewed
* [ ] Acceptance criteria met
* [ ] Functional ...# Feature
## Summary
This MR provides the deletion of project specific code.
## 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
* [ ] Product Owner accepts the User Story
## Documentation
* [ ] 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:
**note:** testing is limited, since the nested motifs aren't merged yet and the icon reproduction is still in place.
- **open** the appropriate **[environment](https://subugoe.pages.gwdg.de/emo/tido/issue--325-ahiqar-code-in-generic-tido/#/)** and **watch** the collection **title** still to be displayed
- **click** the **language toggle** to translate TiDO to German
- expected: the collection title isn't translated anymore
* [ ] 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
#325
## 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/201feat: provide one more zoom lvl in text panel2021-07-22T11:29:59ZNils Windischfeat: provide one more zoom lvl in text panelzoom to the max using the buttons in the text panel and see, that the font size is now 28px (instead of only 24px before).
closes #316zoom to the max using the buttons in the text panel and see, that the font size is now 28px (instead of only 24px before).
closes #316Nils WindischNils Windischhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/192Bugfix/roll back node2021-06-24T09:38:42ZMichelle WeidlingBugfix/roll back node# Bug fix
## Summary
With this MR, we no longer use the latest version of node for our Docker image but `node:12-slim` which doesn't have any problems with libsass.
## Does the result of the MR comply to our "definition of done"?
* [...# Bug fix
## Summary
With this MR, we no longer use the latest version of node for our Docker image but `node:12-slim` which doesn't have any problems with libsass.
## Does the result of the MR comply to our "definition of done"?
* [x] Unit tests passed
* [x] Code reviewed
* [ ] Acceptance criteria met
* [ ] Functional tests passed
* [ ] Non-Functional requirements met
* [x] Product Owner accepts the User Story
/cc [Mathias Göbel](https://gitlab.gwdg.de/mgoebel), [Frank Schneider](https://gitlab.gwdg.de/schneider210), [Michelle Weidling](https://gitlab.gwdg.de/mrodzis)Michelle WeidlingMichelle Weidlinghttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/188text-size-optimization2021-06-18T15:45:15Zschneider210text-size-optimization# Feature
## Summary
This MR provides:
the resizing of the text / content in the text panel by button click (+ / -) taking size limits into account
the default fontsize is set to **1em** which corresponds to **16px**.
either click o...# Feature
## Summary
This MR provides:
the resizing of the text / content in the text panel by button click (+ / -) taking size limits into account
the default fontsize is set to **1em** which corresponds to **16px**.
either click on a button in- or rather decreases the fontsize by **0.125em** which corresponds to **2px** per click.
the minimum is set to **0.875em (14px)** and the maximum to **1.5em (24px)**
## 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
* [ ] 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:
as usual:
- checkout the branch: `git checkout feature/#287-merge-text-size-optimization`
- start your dev env: `npm run dev`
- switch to your browser and point it to **localhost:8080**
- select an arbitrary item of your liking and click on a button at the top of the text panel to in-/decrease the text(-size) therein only
* [ ] 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
#287
### Closes
closes #287
## 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/186move-misc-icons2021-06-21T08:38:08Zschneider210move-misc-icons- refactor **header.vue**
- create new component **@components/tools.vue**
- aggregate **color.vue, language.vue and softwareinfo.vue**
- rename config option **headers** to **header_section** according to @nwindis proposal
- rename...- refactor **header.vue**
- create new component **@components/tools.vue**
- aggregate **color.vue, language.vue and softwareinfo.vue**
- rename config option **headers** to **header_section** according to @nwindis proposal
- rename **headers.all** to **header_section.show**schneider210schneider210https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/185Remove unnecessary config from root dir2021-06-18T07:55:34Zschneider210Remove unnecessary config from root dir- create new folder **.build-scripts** and move **tweak_build.sh** into it
- adjust runner cmd in **package.json** => **npm run tweak:build**
**How to test (on your local)**
- checkout the branch
- `npm run build` (creates a dist folde...- create new folder **.build-scripts** and move **tweak_build.sh** into it
- adjust runner cmd in **package.json** => **npm run tweak:build**
**How to test (on your local)**
- checkout the branch
- `npm run build` (creates a dist folder in the root dir)
- `npm run tweak:build` (patches the quasar build step)
- take a look at the **dist** folder in the root dir; it should now consist of 2 files: **tido.js** and **index.html**
**note**: the **tweak_build**-script is also called **during ci**, so the only possibility to test it before the merge is done, would / could be to make a **dummy commit** and push it.
thereafter you can take a look at the pipeline (gitlab) and watch the job succeed.
=> please revert your changes (dummy commit)schneider210schneider210https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/182Feature/#284 ci add docs2021-06-17T09:43:19ZMichelle WeidlingFeature/#284 ci add docs# Feature
## Summary
This MR provides a more extensive documentation of all things CI.
## Does the result of the MR comply to our "definition of done"?
* [ ] Unit tests passed
* [ ] Code reviewed
* [ ] Acceptance criteria met
* [ ] F...# Feature
## Summary
This MR provides a more extensive documentation of all things CI.
## 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 adjusted other parts of the documentation (if applicable)
## Tests
* [x] No, it is not possible.
## Closes
Closes #284
/cc [Mathias Göbel](https://gitlab.gwdg.de/mgoebel), [Frank Schneider](https://gitlab.gwdg.de/schneider210), [Michelle Weidling](https://gitlab.gwdg.de/mrodzis)Michelle WeidlingMichelle Weidlinghttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/172project header2021-07-07T12:29:43ZNils Windischproject headerThis MR is realated to this epic: https://gitlab.gwdg.de/groups/subugoe/emo/-/epics/8This MR is realated to this epic: https://gitlab.gwdg.de/groups/subugoe/emo/-/epics/8https://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/171style: improve icon spacing of annotations in text panel2021-06-04T07:55:48ZNils Windischstyle: improve icon spacing of annotations in text panelBefore:
![Screenshot_2021-06-04_at_09.01.26](/uploads/1bdf25055a1d62be76e316def54b2429/Screenshot_2021-06-04_at_09.01.26.jpg)
After:
![Screenshot_2021-06-04_at_09.01.00](/uploads/b58752d66481c738d4a2ed087c596b44/Screenshot_2021-06-04_...Before:
![Screenshot_2021-06-04_at_09.01.26](/uploads/1bdf25055a1d62be76e316def54b2429/Screenshot_2021-06-04_at_09.01.26.jpg)
After:
![Screenshot_2021-06-04_at_09.01.00](/uploads/b58752d66481c738d4a2ed087c596b44/Screenshot_2021-06-04_at_09.01.00.jpg)
…works for ltr and rtl text.Nils WindischNils Windischhttps://gitlab.gwdg.de/subugoe/emo/tido/-/merge_requests/170Lean annotation template due to modularization2021-06-15T10:45:56Zschneider210Lean annotation template due to modularization# Feature
## Summary
Follow up from !168
This MR provides the modularization of the annotation component.
Three new components are introduced (annotationtoggles, annotationlist and annotationoptions) to keep the template lean and main...# Feature
## Summary
Follow up from !168
This MR provides the modularization of the annotation component.
Three new components are introduced (annotationtoggles, annotationlist and annotationoptions) to keep the template lean and maintainable and to separate the logic from the markup.
## 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
* [ ] Product Owner accepts the User Story
## Documentation
* [ ] 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 to #158 and #274
### Related
### Closes
closes ${274}
## 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/167Issue/mark annotations in text panel2021-05-21T08:14:57ZNils WindischIssue/mark annotations in text panelsee ticket for acceptance criteria.
test with kashuni collection and see strings with annotation more visible in text panel.
closes #266see ticket for acceptance criteria.
test with kashuni collection and see strings with annotation more visible in text panel.
closes #266Nils WindischNils Windisch