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/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/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/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.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)