Kotahi issueshttps://gitlab.coko.foundation/kotahi/kotahi/-/issues2024-03-27T08:26:17Zhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1571Editing actions on images are retained across versions2024-03-27T08:26:17ZRyan Dix-PeekEditing actions on images are retained across versionsProduction editor version historyhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1570[BPSC] Add collaborative form fields2024-03-25T11:09:01ZRyan Dix-Peek[BPSC] Add collaborative form fields## Context
These enhancements support the implementation of the collaborative reviews. More specifically, targeting the form field types and concurrency.
## Proposal
- YJS collaboration on the following form field components: `TextIn...## Context
These enhancements support the implementation of the collaborative reviews. More specifically, targeting the form field types and concurrency.
## Proposal
- YJS collaboration on the following form field components: `TextInput`, `RichTextEditor`
- Graphql subscriptions to receive real-time updates on `Select`, `SafeRadioGroup`, `CheckboxGroup` and `SupplementaryFiles` -- and server-side logic to ensure that saved values merge with rather than overwrite other recent changes in case of race conditions. YJS is unnecessary for these fields and would provide no real benefits.
- Remove "List of contributors" (`AuthorsInput`) and "List of links" (`LinksInput`) from the set of field types that can be included in reviews. I think these are not used yet by any customer and this would save a lot of work implementing YJS for them. `AuthorsInput` may be replaced with a nested form in future, so implementing YJS for it may be wasted work. Modify the reviews logic to allow a review object with no associated `userId`, but with `collaborative` property set to true. I'm assuming at this stage that there can only be one collaborative review per manuscript version. In future we may need multiple, but that's more work and we can defer until then.
## Design
TBCBPSC Collaborative form field typehttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1569[BPSC] Add ability add reviewer as a 'collaborative' user role2024-03-25T16:03:01ZRyan Dix-Peek[BPSC] Add ability add reviewer as a 'collaborative' user role## Context
## Feature
Add checkbox to the 'Invite Reviewer' modal; 'Collaborate'. Update 'Shared' text; 'Read other submitted reviews'.
## Design
TBC
## Implementation
- User assigned as a 'Collaborate' reviewer should be able to...## Context
## Feature
Add checkbox to the 'Invite Reviewer' modal; 'Collaborate'. Update 'Shared' text; 'Read other submitted reviews'.
## Design
TBC
## Implementation
- User assigned as a 'Collaborate' reviewer should be able to access the same review from the `Review` page.
- Currently, invitations to review are made via the team_members table or the invitations table. invitations.invitedPersonType column will need to support a new value 'COLLABORATIVE_REVIEWER' alongside existing 'AUTHOR' and 'REVIEWER' values. teams.role column will need to support a new value 'collaborativeReviewer'.
- For 'collaborative' reviewers; update `Review` page tab 'Review' to 'Collaborative' review.
- A user can only be added as an individual or collaborative reviewer - for the MVP, they cannot be both assigned an individual and collaborative reviewer.BPSC Collaborative form field typeGiannis Kopanasjkopanas@gmail.comGiannis Kopanasjkopanas@gmail.comhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1568Displaying a 404 error2024-03-25T07:24:01ZRyan Dix-PeekDisplaying a 404 error## Expected behaviour
For multi-tenanted instances, the Favicon should not display for root login page.
## Current behaviour
Favicon should only display per group kotahi/flax pages.
## Steps to reproduce
visit; http://sciety.kotah...## Expected behaviour
For multi-tenanted instances, the Favicon should not display for root login page.
## Current behaviour
Favicon should only display per group kotahi/flax pages.
## Steps to reproduce
visit; http://sciety.kotahi.cloud/
## Environment
Issue only displays when the favicon has been cached by the browser.
## Possible solution
Feedback from Ben
>I believe the reason that favicon is stuck in your cache, even after hard refresh (Ctrl-F5), is because Kotahi is not returning an HTTP 404 error as it should when the favicon is requested, but instead returns an HTML webpage and HTTP code 200 (which means "OK", successfully delivered). Because this is not an image file as expected, the browser assumes that the favicon may still exist but is temporarily inaccessible due to some server error. So it retains the icon it has cached. It will not drop the favicon from its cache unless it gets a 404 "Not found" error, which tells it unambiguously that the favicon doesn't exist.
We should correctly return a HTTP 404 response for any page or asset requested which does not exist. Currently, any non-existent page or asset will always return a blank HTML page (and some javascript) with status 200.
![Screenshot_2024-03-25_at_08.37.23](/uploads/1d08a7398dc9fc1bce309238471c40ad/Screenshot_2024-03-25_at_08.37.23.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1567[ejpimport] Ability to 'unselect' (remove) a label2024-03-28T11:18:29ZRyan Dix-Peek[ejpimport] Ability to 'unselect' (remove) a labelUsers should be able to 'unselect' (apply no value) to a freeform label selection in the 1) Manuscripts table and 2) in the submission form (`submission.$customStatus` form field type). A change in the selection should be reflected in bo...Users should be able to 'unselect' (apply no value) to a freeform label selection in the 1) Manuscripts table and 2) in the submission form (`submission.$customStatus` form field type). A change in the selection should be reflected in both the Manuscripts page and Submission form field.
Manuscripts page;
![Screenshot_2024-03-28_at_13.14.42](/uploads/4552528bad031ad72293fea09a4e026b/Screenshot_2024-03-28_at_13.14.42.png)
Submission form;
![Screenshot_2024-03-28_at_13.17.53](/uploads/e1fd7f4cf696ec4c96ae1bdd48df0933/Screenshot_2024-03-28_at_13.17.53.png)Alexandros GeorgantasAlexandros Georgantashttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1566[Sciety-Colab] Invited author assigned as reviewer2024-03-27T11:28:29ZRyan Dix-Peek[Sciety-Colab] Invited author assigned as reviewer## Expected behaviour
When inviting authors to participate in a peer review; multiple user users (existing/new) can be invited, the user who accepts the invitation should be assigned as the author. A record of the accept or reject actio...## Expected behaviour
When inviting authors to participate in a peer review; multiple user users (existing/new) can be invited, the user who accepts the invitation should be assigned as the author. A record of the accept or reject action is displayed in the Decision>Completed reviews section.
## Current behaviour
When inviting authors to participate in a peer review; if an 'Author invitation' email notification is sent, the second time the author notification is sent to new (different) user, the user appears to be assigned as a reviewer on the Teams>Reviewer Status section.
## Steps to reproduce
1. Editor sends an author invitation to user 1
1. Ueer 1 accepts author invitation
2. Editor sends an author invitation to user 2
3. User 2 is assigned as reviwer on the Control panel>Teams>Reviwer status (review does not appear in Users 2 Dashboard>To review list)
## Possible solution
Ahen an author is invited, this action should not be recorded and displayed on the Team>Reviwer status kanban board.
![Screenshot_2024-03-22_at_11.54.48](/uploads/5d16e75d6082a7cb0113549b690b8b26/Screenshot_2024-03-22_at_11.54.48.png)
![Screenshot_2024-03-22_at_12.13.28](/uploads/97d0368b60e450909718a7316ea61b10/Screenshot_2024-03-22_at_12.13.28.png)Vignesh DevendranVignesh Devendranhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1565BC and TK labels2024-03-20T04:55:09ZAdam Hydeadam@coko.foundationBC and TK labelswe need to develop a form control for traditional knowledge and biocultural labelswe need to develop a form control for traditional knowledge and biocultural labelshttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1564COAR notes2024-03-19T18:00:14ZYannis BarlasCOAR notesThese are some notes that have come up after the COAR notify meeting I attended.
These are not meant as todos (we should make separate issues if it comes to that), more as food for thought.
* We are currently conflating the receiver a...These are some notes that have come up after the COAR notify meeting I attended.
These are not meant as todos (we should make separate issues if it comes to that), more as food for thought.
* We are currently conflating the receiver and the consumer logic. This means that our inbox receives, but also processes a notification. We could separate the inbox from the actual processing. This doesn't necessarily mean that the inbox should be a completely separate service or microservice (though that would be a viable option if we see the benefits).
* The receiver could respond with a 202 status upon receiving a message. This is a continuation of the previous point, where the inbox's job is to receive the message, not to process it necessarily. In this sense, as long as a valid payload has been received, we respond, then the processing happens independently.
* If processing happens separately, and it fails, we can send an error to the original sender of the notification that their request cannot be processed. This would assume though that the original sender can actually receive messages like this.
* We are currently not validating that the payload is valid COAR. Elife seems to already have a validator library in node that we can use.
* We should add different errors for different scenarios. eg. did this fail because there was a validation error, a processing error etc
* Rejection (eg. if someone sends a request for endorsement, which we currently do not support) could be handled differently than an error
* We could have an api endpoint that can describe what the system can do with regards to COAR. This way a sender can use our api and retrieve for example, that we only accept offers for review and that there's a sender whitelist in place, instead of trying to send something to our inbox only to see if it works.
* We should have a handler for the case of receiving a duplicate message.
* We should maybe introduce rate limiting of some sort.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1563Translation overwrite file not being fully applied2024-03-20T09:12:39ZCloud68 Support teamTranslation overwrite file not being fully applied<!-- Required. Provide a general summary of the issue in the title above -->
## Expected behavior
The applied translationoverwrite is used to overwrite other translation
<!-- Required. Tell us what should happen -->
## Current behavior...<!-- Required. Provide a general summary of the issue in the title above -->
## Expected behavior
The applied translationoverwrite is used to overwrite other translation
<!-- Required. Tell us what should happen -->
## Current behavior
After rolling out a new version of Kotahi (v3.1.0) the previously working translation file is not working as intended. It is partly ignored.
<!-- 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. Add a translation file
2. Restart the server or rebuild the container
3. The specified language is present on the user profile
4. The specified translated "terms" are not showing as specified on the file.
## 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. -->Ben WhitmoreBen Whitmorehttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1562Publishing collaborative form field data to Flax2024-03-18T14:16:48ZRyan Dix-PeekPublishing collaborative form field data to Flax## Context
We need to account for collaborative form fields and how we display the data published to Flax.
## Proposal
Publish reviewer names separated by a comma for collaborative reviews (in alphabetical order?). Include anaon
## ...## Context
We need to account for collaborative form fields and how we display the data published to Flax.
## Proposal
Publish reviewer names separated by a comma for collaborative reviews (in alphabetical order?). Include anaon
## Design
![Screenshot_2024-03-18_at_15.08.20](/uploads/f55f1101c6aaa8fd6be9e370a8446819/Screenshot_2024-03-18_at_15.08.20.png)
## Implementation (if applicable)
## Alternative approaches (if applicable)
[Include any alternatives to meet this use case.]https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1561Xsweet Conversion issue2024-03-28T08:27:38Zudhaya kumarXsweet Conversion issue**Description:**
This issue details several conversion problems encountered when using Xsweet to convert documents.
**Specific Issues:**
* Missing Header & Footer Content: The header and footer content from the original document i...**Description:**
This issue details several conversion problems encountered when using Xsweet to convert documents.
**Specific Issues:**
* Missing Header & Footer Content: The header and footer content from the original document is not being preserved during conversion.
* Incomplete Math Elements: Some math elements and symbols, such as the Greek letter Rho (ρ), are missing in certain paragraphs.
* Incorrect Element Parsing: Hyphens (-) are being converted to en-dashes (–), potentially causing unintended formatting changes.
* Image Loss: Images, particularly pie charts and bar graphs, are not being retained in the converted document.
* Disrupted Image Placement: Images initially arranged in a grid or other grouped format are being converted as block-level elements, affecting layout.
* Broken List Content: Certain list types, especially reference lists, are experiencing formatting issues during conversion.
**Steps to Reproduce:**
1\. Upload the attached sample manuscript in POSTMAN and make a call to \`/api/v1/sync/DOCXToHTML\` endpoint in the app.
2\. Compare the output with the original manuscript for above listed occurrences.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1560[CoLab] Register peer review DOIs with Crossref2024-03-25T07:56:44ZRyan Dix-Peek[CoLab] Register peer review DOIs with Crossref## Context
To generate peer review DOIs with Crossref for data capture in a 1) single form (i.e. when using `preprint1` and `preprint2` archetypes) and across multiple forms (i.e. when using `journal` and `prc` archetypes).
The complet...## Context
To generate peer review DOIs with Crossref for data capture in a 1) single form (i.e. when using `preprint1` and `preprint2` archetypes) and across multiple forms (i.e. when using `journal` and `prc` archetypes).
The completion of this task won't allow the Colab team to register review DOIs with Crossref - the Colab markup requirements (relationship between review and editorial data) are bespoke.
## Proposal
To create a configuration page to manage the registering of article and peer review DOIs. A group Manager should be able to select whether an 1) article 2) a summary and/or 3) individual review DOIs can be registered on the publish action.
## Design
TBC
## Implementation (if applicable)
Standardised metadata (Submission), Review and Decision form fields need to be established to ensure the configuration selections can be automated and the relevant required data deposited with Corssref on the publish action.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1559CMS collections manager2024-03-22T12:47:18ZRyan Dix-PeekCMS collections managerMR; https://gitlab.coko.foundation/kotahi/kotahi/-/merge_requests/1147MR; https://gitlab.coko.foundation/kotahi/kotahi/-/merge_requests/1147Giannis Kopanasjkopanas@gmail.comGiannis Kopanasjkopanas@gmail.comhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1558Some pages do not have language localisation2024-03-14T05:11:40Zudhaya kumarSome pages do not have language localisationSome pages are not translated
1. **Title heading is not changed in all the table**
![image](/uploads/e6dbeb30cbfa72d5340b4742e4027bff/image.png)
2. **Control > Decision** (page—paragraph ,decision page, accept ,reject, revise)
![ima...Some pages are not translated
1. **Title heading is not changed in all the table**
![image](/uploads/e6dbeb30cbfa72d5340b4742e4027bff/image.png)
2. **Control > Decision** (page—paragraph ,decision page, accept ,reject, revise)
![image](/uploads/66010fb9b50d5c28d26446b73dfc6d6e/image.png)
3. **Setting -> Forms -> Submission**
![image](/uploads/a0db52658dfb99fbaf949585976424e9/image.png)
4. **Setting -> Forms -> Decision**
![image](/uploads/62f39e71fd515c9cddf27f13c2f4f0e5/image.png)
5. **Setting -> Forms -> Review**
![image](/uploads/c03d7bcbb1633546612409d7943c361b/image.png)
6. **Setting ->Emails**
![image](/uploads/677f6e775b7b5e9f00e2d98dd8d6de59/image.png)
7. **Wax Editor test are not translated**
![image](/uploads/5549303f4d42381f8fdd8b99c8711cfb/image.png)
.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1557Reviewers should only be able to be invited manually or using the Reviewer in...2024-03-27T11:47:01ZRyan Dix-PeekReviewers should only be able to be invited manually or using the Reviewer invitation## Expected behaviour
An editor should only be able to invite a single user once to participate in a round of review.
## Current behaviour
Currently, a user editor can be assigned manually and using the 'Reviewer invitation' email noti...## Expected behaviour
An editor should only be able to invite a single user once to participate in a round of review.
## Current behaviour
Currently, a user editor can be assigned manually and using the 'Reviewer invitation' email notification template.
## Steps to reproduce
1. Assign a reviewer from the Control panel>Teams page>Invite reviewers section, ensure 'Email notification' is unselected
2. Assign the same user from the Control panel>Teams page>Invite reviewers section and select 'Email notification' for the Invite reviwer modal.
3. Notice both users appear in the Control panel>Teams page>Reviwer stutas>'Invited' column
## Possible solution
- A user should only be able to be assigned once to a round of review. The user card should only appear once in the 'Invited' list (column).
- If a user is invited they should be able to receive multiple email notifications to participate in a single round of review.
- If a user is invited manually and sent a 'Reviewer invitation' email notification thereafter, the same user card should be updated to reflect 'Invoted via email'.
![Screenshot_2024-03-11_at_08.02.36](/uploads/b6c2c1cf2e7d5dc6c7316fcff1d947a1/Screenshot_2024-03-11_at_08.02.36.png)Vignesh DevendranVignesh Devendranhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1556Review page access is revoked when new version is submitted2024-03-27T11:55:06ZRyan Dix-PeekReview page access is revoked when new version is submitted## Expected behaviour
As a reviewer, I'm unable to see my previous submitted reviews under Dashboard>My reviews.
## Current behaviour
When an author submits a new version of a manuscript the, Reviewers who has previously submitted a ...## Expected behaviour
As a reviewer, I'm unable to see my previous submitted reviews under Dashboard>My reviews.
## Current behaviour
When an author submits a new version of a manuscript the, Reviewers who has previously submitted a review can no longer see their reviews - access has been revoked.
## Steps to reproduce
1. Assign a reviewer
2. Reviewer submits a review
3. Editor submits 'Revise' decision
4. Author submits a new version
4. Reviewer is unable to see previously submitted review in the Dashboard>My Reviews list, and clicking on the 'Accept' link from email notification displays a restricted access notice (token is no longer available)
## Possible solution
Related MRs;
- https://gitlab.coko.foundation/kotahi/kotahi/-/merge_requests/1103
- https://gitlab.coko.foundation/kotahi/kotahi/-/merge_requests/1124Ben WhitmoreBen Whitmorehttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1555Unsubmitted reviews are not being saved2024-03-27T11:39:54ZRyan Dix-PeekUnsubmitted reviews are not being saved## Expected behaviour
Reviwes accessing and editing the Review page>Review tab should be able to edit form content, end session and return to their review and data should be saved and editable.
## Current behaviour
Data input into th...## Expected behaviour
Reviwes accessing and editing the Review page>Review tab should be able to edit form content, end session and return to their review and data should be saved and editable.
## Current behaviour
Data input into the review page is not saved and not submitted is not saved when the reviewers ends the session.
## Steps to reproduce
<!-- Required. Provide a link to a live example or screenshots, and the steps to reproduce this bug.]-->
1. Assign a reviewer to a review
2. Reviewers access the review page and inputs data into any field
3. navigate to the dashboard or click refresh
## Possible solution
Data should saved on blurVignesh DevendranVignesh Devendranhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1554MathType failures2024-03-07T13:12:35ZDan ViselMathType failuresIn the document binarymath2.docx, there's an equation that looks like this in Pages:
![Screenshot_2024-03-07_at_2.04.04_PM](/uploads/65fd0d31dcecaca5a4f8a638f10b389f/Screenshot_2024-03-07_at_2.04.04_PM.png)
That's not being translated ...In the document binarymath2.docx, there's an equation that looks like this in Pages:
![Screenshot_2024-03-07_at_2.04.04_PM](/uploads/65fd0d31dcecaca5a4f8a638f10b389f/Screenshot_2024-03-07_at_2.04.04_PM.png)
That's not being translated into an equation in Kotahi; we get a missing image error. There's something odd going on in the equation as Pages shows it (which has been converted to an image); there's a `ò` which probably should be something else.
A second equation in the same document looks like this:
![Screenshot_2024-03-07_at_2.05.29_PM](/uploads/2f055cb0b9bc3d9114253123d3b67303/Screenshot_2024-03-07_at_2.05.29_PM.png)
(again note the `ò`); this comes in as an equation in Kotahi, but it looks like this:
![Screenshot_2024-03-07_at_2.09.12_PM](/uploads/43fb323a81b4c1c5c174a2adac6dccf7/Screenshot_2024-03-07_at_2.09.12_PM.png)
and double-clicking the equation reveals that its LaTeX source is this:
```
rightcenter_baseline0001\text{F}\text{i}\text{r}\text{s}\text{t}\text{s}\text{t}\text{a}\text{g}\text{e}:ClaimedCredit0_{1c,a,t}1=α+ϕ12PredCredit0_{1c,t}1+X_{c,a,t}^{′}β+ω0_{1c}1+τ0_{1t}1+ρ0_{1a}1+50ϵ0_{1c,a,t}1\text{S}\text{e}\text{c}\text{o}\text{n}\text{d}\text{s}\text{t}\text{a}\text{g}\text{e}:P0_{1c,a,t}1=α+ϕ01ClaimedCredit̂0_{1c,t}1+X_{c,a,t}^{′}β+ω0_{1c}1+τ0_{1t}1+ρ0_{1a}1+ϵ0_{1c,a,t}
```
Something is wrong in there, but I don't know if it's:
1) some kind of non-standard LaTeX being used;
2) the MathType gem decoding this wrong; or
3) MathJax in Kotahi not supporting this part of LaTeX.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1553[BPSC] Unarchive manuscripts2024-03-27T23:36:58ZRyan Dix-Peek[BPSC] Unarchive manuscripts## Context
Group Managers can 'Archive' manuscripts from the Manuscripts page. These manuscripts are removed from the Manuscripts list but are not deleted from the database. This task aims to support the search and unarchiving of archiv...## Context
Group Managers can 'Archive' manuscripts from the Manuscripts page. These manuscripts are removed from the Manuscripts list but are not deleted from the database. This task aims to support the search and unarchiving of archived manuscripts.
## Proposal
1. Create an action on the Manuscripts page to display archived manuscripts. Group Managers should be able to use existing pagination, keyword search, date/status/label filters and sort features to navigate the 'unarchived' manuscripts list.
1. Add an 'unarchive' option to the 'Actions' dropdown list on the Manuscripts page.
1. Users should not be able to archive published manuscripts.
1. Hide 'Control panel' and 'Production' pages links from the unarchived manuscripts view.
1. Remove 'Archive' link per manuscript on the Manuacrupts page.
## Design
[TBC]BPSC Collaborative form field typehttps://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.com