Kotahi issueshttps://gitlab.coko.foundation/kotahi/kotahi/-/issues2024-03-22T12:47:16Zhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1552Expose CMS files2024-03-22T12:47:16ZRyan Dix-PeekExpose CMS filesExpose CMS files in CMS>Files.MR; https://gitlab.coko.foundation/kotahi/kotahi/-/merge_requests/1111Expose CMS files in CMS>Files.MR; https://gitlab.coko.foundation/kotahi/kotahi/-/merge_requests/1111Giannis Kopanasjkopanas@gmail.comGiannis Kopanasjkopanas@gmail.comhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1550[i18n] Form labelling translations2024-03-06T06:18:24ZBen Whitmore[i18n] Form labelling translationsSupport multiple languages for labels in dynamic forms, so that forms can be displayed in the user's selected language, both in editable and readonly mode. (This will also facilitate aspects of translations to Flax and possibly other exp...Support multiple languages for labels in dynamic forms, so that forms can be displayed in the user's selected language, both in editable and readonly mode. (This will also facilitate aspects of translations to Flax and possibly other exports -- not covered in this ticket.)
This ticket does _not_ cover data entry in multiple languages, e.g. allowing a user to enter multiple abstracts in English, Russian and French. That would need to be considered in a separate ticket.
## Labels that can be translated
When a user chooses their preferred language in the UI, this should also change the language of the following data items:
- form title (`name`)
- form description (`description` -- rich text)
- form submission-confirmation modal title (`popuptitle`)
- form submission-confirmation modal text (`popupdescription` -- rich text)
- field title (`title`)
- field short-form title (`shortDescription`)
- field description (`description` -- rich text)
- field placeholder (`placeholder`)
- select/radio/checkbox field option label (`label`)
## Data structure
Currently each of the above data items are stored as a string in the form, representing either **plain text** or **html** ('rich text'). We should in each case replace the string with an **array of `{ label: string, lang: string }`**. Example of data for a field title:
```
[{ label: 'Abstract', lang: 'en' }, { label: 'Реферат', lang: 'ru-RU' }]
```
To keep the data tidy, empty string translations should be removed from the array.
We'll need to provide migrations for existing forms to move to the new structure.
## Form-builder changes
In the form-builder, text entry components will need to change. Current state:
![image](/uploads/a19260a3a1c401f78e0131bcd77564f0/image.png)
These should change to
![image](/uploads/11859f424b80f6c3ea3ef65c780370eb/image.png)
Clicking the globe icon (`react-feather` `Globe`) toggles expanding it to the following:
![image](/uploads/259ac0766ddad8106262336892649305/image.png)
Similarly, for rich text data items:
![image](/uploads/99f83f6fa65a8466f7ee79b87fb7c15c/image.png)
The language options displayed, and the 'default' language shown when the options are collapsed, should be configured via the config manager (details below). The examples above show what would display if the default language is configured to be English, and subsequent languages are Russian and French (in that order).
When editing _required_ fields, only the default language is required.
### Alerting users to missing translations (in the form-builder)
If a form contains any translations other than the default language for _any_ data item in the form, the globe icon should be shown in warning colour for _all_ data items that don't have translations for _all_ configured languages. E.g., if the default language is English, and a form only contains English translations, globe icons should all be normal colour; but then let's say the user adds a French translation for a field placeholder text: now the globe icons of every data item in that form are displayed in warning colour unless _all_ language translations are supplied for that data item. Globe icons in warning state should have tooltips saying e.g. "Русский, Français not supplied".
## Config manager changes
In the config manager the list of supported languages can be configured: this is stored as an array of `{ label: string, lang: string }`, where the user enters the `label` as e.g. "Русский" and the `lang` as e.g. 'ru-RU'. This is displayed as a list of language items, each with two text fields ("Language name" and "ISO 639-1 tag"). Languages in the list can be reorganised, and the first in the list is taken to be the default language.
## Displaying labels in forms
The `FormTemplate` and `ReadOnlyFormTemplate` components should in each case choose the best label to display, according to what translations are available. Order of precedence is:
1. the user's current selected language
2. the default language (first language listed in config manager)
3. second language listed in config manager
4. etc.
The first available label (with a non-empty string) in this order of precedence is the label chosen for display.Ivan_AlexandrinaIvan_Alexandrinahttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1549Flax stats2024-03-04T00:07:01ZAdam Hydeadam@coko.foundationFlax statswe can embed graphs etc from matamo (open source web analytics app) into kotahi pages. this would be a cheap way to get high resolution tracking stats from flax into a group:
https://matomo.org/guide/reporting-tools/embedding-matomo/
I...we can embed graphs etc from matamo (open source web analytics app) into kotahi pages. this would be a cheap way to get high resolution tracking stats from flax into a group:
https://matomo.org/guide/reporting-tools/embedding-matomo/
IMHO we need a switch in config for matamo (\[\] use matamo for stats\]
if checked, then :
1. we need to fill out the source for the target matamo install and api key etc.
2. a new page in reports should appear 'web stats' with the embeded graphshttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1546Suggested changes and comments not dispayed to authors across versions2024-02-29T06:16:04ZRyan Dix-PeekSuggested changes and comments not dispayed to authors across versionsAfter creating a new version, when accessing the Manuscripts page, authors cannot see suggested changes/comment annotations.
## Expected behaviour
Authors should be able to see track changes/Comments annotations on the Manuscripts text...After creating a new version, when accessing the Manuscripts page, authors cannot see suggested changes/comment annotations.
## Expected behaviour
Authors should be able to see track changes/Comments annotations on the Manuscripts text page.
## Current behaviour
For a traditional publishing workflow, when editing manuscripts in Wax; authors can see suggested changes inline, but not the annotations or comments when accessing the content from the `/submit`> Manuscripts.
## Steps to reproduce
1. Author submits docx
2. Group Manager adds suggested changes/comments in Production editor
3. Editor/Group Manager set Decision to 'revise' and submits
4. Author creates a new version
5. Author access Manuscripts text page - can see inline track changes but not the annotations
## Environment
Persists on v3.0.2
![Screenshot_2024-02-29_at_07.35.57](/uploads/b5646eda330fc238c8900c1ec99655fa/Screenshot_2024-02-29_at_07.35.57.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1544Update of SQL dumps used for cypress testing2024-03-01T13:44:32ZSidorela UkuUpdate of SQL dumps used for cypress testingSince the last update of the dump files, some fields in the db have changed or are added new. And this impact the result of the tests output to not match the current development status.
There few cases in review that should have failed ...Since the last update of the dump files, some fields in the db have changed or are added new. And this impact the result of the tests output to not match the current development status.
There few cases in review that should have failed but they still are successful, considering that issue #1504 is not yet implemented.
I will open a new MR to follow up with the updates in the dump files used for the automated testing.Sidorela UkuSidorela Ukuhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1543title tags need to encode marks correctly2024-03-07T18:31:43ZCloud68 Support teamtitle tags need to encode marks correctlyIn this example, headers have bold and italic in them. When exported to JATS, the `<strong>` and `<em>` are not encoded correctly, and we get something like this:
```
<title>Commentaries on &lt;em&gt;Nanothermodynamics&lt;/em&gt;</title...In this example, headers have bold and italic in them. When exported to JATS, the `<strong>` and `<em>` are not encoded correctly, and we get something like this:
```
<title>Commentaries on <em>Nanothermodynamics</em></title>
```
which should be
```
<title>Commentaries on <italic>Nanothermodynamics</italic></title>
```
The unescaped ampersands cause the XML to be invalid to the parser. We need to process these marks correctly.
---
(previous report:)
<!-- Required. Provide a general summary of the issue in the title above -->
## Expected behavior
When trying to download JATS on production an error will be shown mentioning that the JATS is invalid.
the following log is from console
```
Error making JATS. Errors: {"err":{"code":"InvalidChar","msg":"char '&' is not expected.","line":1,"col":20441}}
```
no errors are shown on the container logs
<!-- Required. Tell us what should happen -->
## Current behaviour
<!-- Required. Tell us what happens instead of the expected behaviour -->
## Steps to reproduce
<!-- Required. Provide a link to a live example or screenshots, and the steps to reproduce this bug.]-->
1. create a new manuscript
2. add your data
3. submit it
4. go to production
5. download JATS
6. get a link but the error of invalid JATS is shown
## Environment
<!-- Required. Provide relevant information such as browser name and version, PC or Mac use, internet speed, etc.]-->
## Possible solution
<!-- If known, provide details on how to fix the bug.-->
<!-- After creating this issue you can link other related or blocking issues with the Gitlab's Linked issues functionality. -->Dan ViselDan Viselhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1542Folmulas not being formated correctly on the html export2024-02-22T10:20:33ZCloud68 Support teamFolmulas not being formated correctly on the html export<!-- Required. Provide a general summary of the issue in the title above -->
## Expected behaviour
<!-- Required. Tell us what should happen -->
## Current behavior
<!-- Required. Tell us what happens instead of the expected behaviou...<!-- Required. Provide a general summary of the issue in the title above -->
## Expected behaviour
<!-- Required. Tell us what should happen -->
## Current behavior
<!-- Required. Tell us what happens instead of the expected behaviour -->
When downloading an HTML from a manuscript the formulas on it will not be formatted correctly, they are displayed as they are written on the manuscript.
## Steps to reproduce
<!-- Required. Provide a link to a live example or screenshots, and the steps to reproduce this bug.]-->
1. create a new manuscript
2. publish it
3. try to download a html version of it
4. you will get a html with not formatted formulas
## Environment
<!-- Required. Provide relevant information such as browser name and version, PC or Mac use, internet speed, etc.]-->
## Possible solution
<!-- If known, provide details on how to fix the bug.-->
<!-- After creating this issue you can link other related or blocking issues with the Gitlab's Linked issues functionality. -->https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1541update to Cokoserver v32024-03-27T12:41:08ZRyan Dix-Peekupdate to Cokoserver v3Yannis BarlasYannis Barlashttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1540[BPSC] Edit Collaborative form field data from the Control panel2024-03-12T09:34:31ZRyan Dix-Peek[BPSC] Edit Collaborative form field data from the Control panelThe purpose of the task is to allow editors to access and edit content saved in a Collaborative form field.
**Workflow overview**
PEER REVIEW
1. Trainee Reviewer reads the paper.
1. Trainee Reviewer drafts a review.
1. Trainee Reviewe...The purpose of the task is to allow editors to access and edit content saved in a Collaborative form field.
**Workflow overview**
PEER REVIEW
1. Trainee Reviewer reads the paper.
1. Trainee Reviewer drafts a review.
1. Trainee Reviewer messages Expert Reviewer that draft is ready for review.
1. Expert Reviewer reviews and makes suggestions.
1. Expert Reviewer notifies the Trainee Reviewer that the review needs edits.
1. Trainee Reviewer revises review (returns to step 5).
1. Expert Reviewer hands review over to Editor.
EDITORIAL REVIEW
1. Editor reviews.
1. Editor makes changes
1. If the review needs more work, the editor adds comments for the reviewers and notifies the Trainee Reviewer and Expert Reviewer of the need for edits. (Return to step 5 above).
1. Editor adds comments to reviewers and submits.
The solution;
- Reviewers will be assigned a 'collaborative' state on invite action.
- Collaborative reviewers will see the same Review form fields, and non-collaborative reviewers will access their own Review form on the `/review` page.
- Completed and Collaborative reviews will be displayed on the Control panel>Review page (see #1428).
- For collaborative reviews, editors will be able to control edit access to the Review page using a locking/unlocking control. A 'locked' Review page will still be accessible in a read-only state.
**Acceptance criteria;**
- [ ] Add checkbox to the 'Invite Reviewer' modal; 'Collaborate'. Update 'Shared' text; 'Read other submitted reviews'
- [ ] 'Collaborative Reviews' will be displayed on the Control panel>Review tab under a section below 'Submitted Reviews' - if there are no collaborative reviews, then the section should be hidden.
- [ ] The editor can lock collaborative form fields, which will allow collaborative reviewers read-only access on the Review page, or unlock allowing collaborative reviewers edit access to the Review page. Display a [lock](https://feathericons.com/?query=lock) or [unlock](https://feathericons.com/?query=unlock) on the Control panel>Revies>Collaborative Reviews card (TBC).
- [ ] The editor can always access and edit content within the current version. When a new version of the manuscript is created, the content of the collapsable form field is read-only.BPSC Collaborative form field typeGiannis Kopanasjkopanas@gmail.comGiannis Kopanasjkopanas@gmail.comhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1537[BPSC] Metadata missing from imported manuscripts2024-02-28T06:35:16ZRyan Dix-Peek[BPSC] Metadata missing from imported manuscriptsMetadata missing from imported preprints/articles; Title, DOI, Abstract, Link
I suspect this may be due to the updates made to the form builder and the associated mapping.
![Screenshot_2024-02-20_at_05.59.16](/uploads/4222cf96ebacbbd...Metadata missing from imported preprints/articles; Title, DOI, Abstract, Link
I suspect this may be due to the updates made to the form builder and the associated mapping.
![Screenshot_2024-02-20_at_05.59.16](/uploads/4222cf96ebacbbd2e485dcfe2ca2257a/Screenshot_2024-02-20_at_05.59.16.png)
![Screenshot_2024-02-20_at_06.00.11](/uploads/b0aa97b5fb619f5ca772c1eb113b39e3/Screenshot_2024-02-20_at_06.00.11.png)BPSC Collaborative form field typehttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1533Better image management in Flax2024-02-15T20:27:36ZBen WhitmoreBetter image management in Flax(Based on a comment here: https://gitlab.coko.foundation/kotahi/kotahi/-/merge_requests/1141#note_135056)
Our current approach to inserting images in Flax templates requires modifying the templates every time we publish, using regex sear...(Based on a comment here: https://gitlab.coko.foundation/kotahi/kotahi/-/merge_requests/1141#note_135056)
Our current approach to inserting images in Flax templates requires modifying the templates every time we publish, using regex search/replace to update the `src` attribute in every image tag. This is hacky and fragile and breaks the principle that the template should be essentially a static file that changes only when the user decides they want to modify layout.
Currently, if you copy/paste an image asset into your template, you get something like this:
```
{{ '<img data-name="rose.png" data-id="68e1ed6f-c31e-47e1-a332-1c229d216c6d" src="http://filehosting:9000/uploads/ad5a0a8cd860.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=nonRootUser%2F20240215%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240215T192026Z&X-Amz-Expires=86400&X-Amz-Signature=3d62d7451101ac5448a4405b814efff0bdcd0ab262b494720ab30aadff6288ee&X-Amz-SignedHeaders=host" alt="rose.png" />' | imagesHandler(article.shortId, 'articles', config.group, cmsLayout.hexCode) | makeSvgsFromLatex(true) | safe }}
```
This is inherently fragile because the `src` will soon expire. We should instead be inserting something like this:
```
<img src="{{ assets.6jX8mOe1 }}" alt="foo.png" />
```
where junjucks will replace `{{ assets.6jX8mOe1 }}` with `/kotahi/assets/images/articles/6jX8mOe1-foo.png` (or whatever path Flax has saved the asset to).
In the 'Template assets' tab, the numeric ID currently displayed for each asset is meaningless, as it will change if an earlier asset in the list is deleted: The ID does not stay with the asset for its lifetime. I recommend instead providing a short unique ID such as '6jX8mOe1' that will emable the user to match asset tags from the template with assets in the list.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1531Author cannot add comments or see track changes in Manuscripts text editor2024-02-15T06:49:12ZRyan Dix-PeekAuthor cannot add comments or see track changes in Manuscripts text editorAs an author, when I submit a docx and access the manuscripts content form `/submit` page Manuscripts text page;
1. I can annotate text but cannot add a comment.
1. I can enable 'Suggesting' mode and apply track changes, but I am unable...As an author, when I submit a docx and access the manuscripts content form `/submit` page Manuscripts text page;
1. I can annotate text but cannot add a comment.
1. I can enable 'Suggesting' mode and apply track changes, but I am unable to see the track change annotations.
The above issues persist if the wax editor is expanded/collapsed. Comments and track changes should be visible when permitted.
![Screenshot_2024-02-15_at_08.44.38](/uploads/7f48286ee659f6ab6d86c83c71512f68/Screenshot_2024-02-15_at_08.44.38.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1527Manuscript status filtering displays irrelevant options2024-02-13T05:30:47ZRyan Dix-PeekManuscript status filtering displays irrelevant optionsCurrently, a user can filter by Status from the Dashboard and Manuscripts pages. All statuses are displayed as selection options despite 1) the relevance and 2) selection. So you see a status that may have no meaning within the context o...Currently, a user can filter by Status from the Dashboard and Manuscripts pages. All statuses are displayed as selection options despite 1) the relevance and 2) selection. So you see a status that may have no meaning within the context of a given group workflow and can be filtered despite there being no results to display.
The suggestion; remove all hardcoded status selections from the dropdown menus and only display status options that have results. So if a Manuscript is imported, it would be 'Unsubmitted' or an author's submission may be 'Submitted' or a Manuscript that has been 'Published'.
![Screenshot_2024-02-13_at_07.30.19](/uploads/c1ba2286c9696941feb438f6baf824a7/Screenshot_2024-02-13_at_07.30.19.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1526Unable to save special parsing/formatting form field settings2024-03-15T10:42:03ZRyan Dix-PeekUnable to save special parsing/formatting form field settingsGroup Managers can apply a Special parsing/formatting form field setting, but clicking on 'update' does not save the selection. There is also a selection option 'None' - this seems redundant, the only selection options should be Special ...Group Managers can apply a Special parsing/formatting form field setting, but clicking on 'update' does not save the selection. There is also a selection option 'None' - this seems redundant, the only selection options should be Special prasing>Split at comma and Special fomratting>Join at commas. 'None' should be null or the default value when Split at comma/Join at commas. have not been selected.
![Screenshot_2024-02-12_at_08.48.31](/uploads/a5917212430aaa3357dee09ffb2b50af/Screenshot_2024-02-12_at_08.48.31.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1524Researcher Model2024-02-13T07:43:47ZAdam Hydeadam@coko.foundationResearcher ModelWe want to create the possibility for research labs to publish by themselves. Their workflow is, in a sense, 'academic blogging'. A simple workflow.
In the researcher workflow Kotahi is essentially stripped down to :
1. dash
2. article...We want to create the possibility for research labs to publish by themselves. Their workflow is, in a sense, 'academic blogging'. A simple workflow.
In the researcher workflow Kotahi is essentially stripped down to :
1. dash
2. article (editor)
3. manuscripts page (only for those with perms)
Articles are started by authors, and the sharing mechanism (from Ketida) enables shared editing.
The trick is going to make it _feel_ like it was built for this flow...we need to remove as much stuff as we need to add. Remove, for example, links to the control panels (no need for them), possibly hide task manager template editor in settings etc... the cleaner it feels the better.
Items for dev:
stage 1
* change text from 'create submission' to 'create post' on dash and manuscript (config - Mathias)
* comments plugin in flax (Julien)
* publish button on manuscripts page (config - Vukile)
* publish button on article (config - Vukile)
* bring manuscript tab infront of metadata in view (config - Mathias)
* hide control page links (config - Mathias)
stage 2
* enable a config in settings to model what kind of submissions we are talking about - attachment, url,docx, data only, writing manuscript
* bring citation manager to editor (christos)
* sharing button on article interface for multiple authors (config - Giannis)
* concurrency (Giannis)
* 1 min migrations target
* ![Screenshot from 2024-02-11 16-26-55.png](/uploads/30cb120cef1c183685f2188335b50ad0/Screenshot_from_2024-02-11_16-26-55.png)Vukile LangaVukile Langahttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1522Author unable to add comments from Manuscripts text editor2024-02-08T09:03:15ZRyan Dix-PeekAuthor unable to add comments from Manuscripts text editorAs an author, I can annotate text and see the icon to add a comment. But clicking on the icon is unresponsive. I'm unable to see the comments box to insert text - this is true in the expanded view of the editor as well. I should at least...As an author, I can annotate text and see the icon to add a comment. But clicking on the icon is unresponsive. I'm unable to see the comments box to insert text - this is true in the expanded view of the editor as well. I should at least be able to see the comments box the the editor viewport in both expanded or minimised states;
![Screen_Recording_2024-02-08_at_10.54.03](/uploads/c6489f14d851b983d6a63f70b8da8384/Screen_Recording_2024-02-08_at_10.54.03.mov)
![Screenshot_2024-02-08_at_11.00.37](/uploads/d12eb8854010b5ee1d59de705fcfed13/Screenshot_2024-02-08_at_11.00.37.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1520Re-jig the left menu2024-02-05T06:35:57ZAdam Hydeadam@coko.foundationRe-jig the left menufor 3.1 release
Items shoudl be:
Dashboard _(always shown)_
---
**Editorial** _(collapsible)_
All Manuscripts
Users
Reports
---
**CMS** _(collapsible)_
Pages
Layout
Article Template
---
**Settings** _(collapsible)_
General...for 3.1 release
Items shoudl be:
Dashboard _(always shown)_
---
**Editorial** _(collapsible)_
All Manuscripts
Users
Reports
---
**CMS** _(collapsible)_
Pages
Layout
Article Template
---
**Settings** _(collapsible)_
General Configuration
Email Templates
Task Templates
Forms _(collapsible)_
_(submission, Review, Decision)_https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1519Change 'Header' in title to 'Menu'2024-02-05T06:36:32ZAdam Hydeadam@coko.foundationChange 'Header' in title to 'Menu'for 3.1 release
in the CMS the attached image it displays 'header' replace with menu. this is really for managing the menu, nothing to do with any form of 'header'
![Screenshot from 2024-02-05 12-24-09.png](/uploads/82905bd4d4c6ff4d6d7...for 3.1 release
in the CMS the attached image it displays 'header' replace with menu. this is really for managing the menu, nothing to do with any form of 'header'
![Screenshot from 2024-02-05 12-24-09.png](/uploads/82905bd4d4c6ff4d6d7a870f7c18424f/Screenshot_from_2024-02-05_12-24-09.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1518Equations in image format2024-02-05T08:52:26Zmadhan mEquations in image formatThe common issue across all files is that the equations are in Image format. so that xsweet doesn't recognise them as equations instead recognises them as images.
Currently xsweet converts equations only if the following format is in th...The common issue across all files is that the equations are in Image format. so that xsweet doesn't recognise them as equations instead recognises them as images.
Currently xsweet converts equations only if the following format is in the document.
But in the case of the sample files xsweet is unable to recognise the equations if it is in image format as in the below attached image.
Please find the attached manuscript for the same as well[27353-Manuscript-196158-1-2-20221026.docx](/uploads/7ea656694942ced6e9232ace1c1cd8ec/27353-Manuscript-196158-1-2-20221026.docx)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1517deleting CMS page crashes2024-01-31T06:02:11ZDan Viseldeleting CMS page crashesMake a new CMS page, save it, go to another page in the CMS, go back to the first one, press Delete. The page is deleted but there's a white screen.Make a new CMS page, save it, go to another page in the CMS, go back to the first one, press Delete. The page is deleted but there's a white screen.