Kotahi issueshttps://gitlab.coko.foundation/kotahi/kotahi/-/issues2023-10-31T11:18:00Zhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1456[eLife] Submissions in Kotahi are preregistered in bioRxiv2023-10-31T11:18:00ZRyan Dix-Peek[eLife] Submissions in Kotahi are preregistered in bioRxiveLife workflow that is required;
1. Author submits to Kotahi (elife), on successful submission
2. the editor selects manuscripts for review
3. the manuscript is sent to bioRxiv, and preregistered (so no DOI is issued, but an `id` is ass...eLife workflow that is required;
1. Author submits to Kotahi (elife), on successful submission
2. the editor selects manuscripts for review
3. the manuscript is sent to bioRxiv, and preregistered (so no DOI is issued, but an `id` is assigned to the manuscript)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1454Multilanguage Flax2024-03-14T04:27:37ZLinar_Alexandrinalinar.habibullin@alexandrina.techMultilanguage FlaxLinar_Alexandrinalinar.habibullin@alexandrina.techLinar_Alexandrinalinar.habibullin@alexandrina.techhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1446Form builder pagination2023-10-20T04:24:43ZRyan Dix-PeekForm builder paginationhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1441Add manual upload of group logo2023-12-20T10:36:45ZAdam Hydeadam@coko.foundationAdd manual upload of group logoIn settings:
![Screenshot from 2023-10-17 09-25-42.png](/uploads/2b26a564cc236ccb3fde2a603d8d9cc7/Screenshot_from_2023-10-17_09-25-42.png)
the last item (logo) needs to be a manual upload process.In settings:
![Screenshot from 2023-10-17 09-25-42.png](/uploads/2b26a564cc236ccb3fde2a603d8d9cc7/Screenshot_from_2023-10-17_09-25-42.png)
the last item (logo) needs to be a manual upload process.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1439Add the create task button to the top of the task list2023-12-20T10:41:32ZAdam Hydeadam@coko.foundationAdd the create task button to the top of the task listWhen creating tasks i found that i had to scroll to the bottom of the task list each time. It would be preferable to also have the '+' at the top of the task list. (keep it at the top and at the bottom).When creating tasks i found that i had to scroll to the bottom of the task list each time. It would be preferable to also have the '+' at the top of the task list. (keep it at the top and at the bottom).https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1437Math not rendered in chat2023-10-17T12:59:20ZAdam Hydeadam@coko.foundationMath not rendered in chatI am not seeing math render in the chat editor. See attached image
![Screenshot from 2023-10-14 23-57-45.png](/uploads/3c245e949841263f4d0767b8c5281e3f/Screenshot_from_2023-10-14_23-57-45.png)I am not seeing math render in the chat editor. See attached image
![Screenshot from 2023-10-14 23-57-45.png](/uploads/3c245e949841263f4d0767b8c5281e3f/Screenshot_from_2023-10-14_23-57-45.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1433xSweet Math Equations Latex conversion2023-12-20T12:22:01ZRavindhar RangarajanxSweet Math Equations Latex conversionHi Team,
In the previous versions of Kotahi, the XSweet microservice consistently delivered math equations in a LaTeX standard that precisely matched our requirements. However, we have observed that the current version(2.0) of XSweet i...Hi Team,
In the previous versions of Kotahi, the XSweet microservice consistently delivered math equations in a LaTeX standard that precisely matched our requirements. However, we have observed that the current version(2.0) of XSweet is converting math equations into a different standard, which does not align with our needs.
To provide clarity and context, I have attached documents that highlight the differences between the previous and current conversion standards. These documents should illustrate the disparities and challenges we are currently facing.
Current version: [current_xsweet_conversion.docx](/uploads/347e5a234e9388bfc2afc0aadeeb757f/current_xsweet_conversion.docx)
Previous version:[Previous_xsweet_conversion.docx](/uploads/8d05df5df300a92e106b24b64e3d8a03/Previous_xsweet_conversion.docx)
It will be helpful if you can provide a fix asap.Dan ViselDan Viselhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1432Table conversion column ordering issue2023-09-28T07:21:21ZRyan Dix-PeekTable conversion column ordering issueOn import, the following manuscript table columns order is displayed in the full wax/production editor from right to left, instead of right to left. The tables should be imported and retain the column styling.
Example; https://kotahi.k...On import, the following manuscript table columns order is displayed in the full wax/production editor from right to left, instead of right to left. The tables should be imported and retain the column styling.
Example; https://kotahi.kotahidev.cloud68.co/kotahi/versions/36d03b73-cdcd-4f77-b4f5-29a34e64e815/decision
Manuscript screenshot;
![Screenshot_2023-09-18_at_12.45.37](/uploads/5eb4263e4038e4753eabfa7dd90e587f/Screenshot_2023-09-18_at_12.45.37.png)
Kotahi full wax editor view;
![Screenshot_2023-09-18_at_12.45.00](/uploads/ad2d4a51bc0c46aa5f27a94aaa11b78d/Screenshot_2023-09-18_at_12.45.00.png)
XSweet demo view;
![Screenshot_2023-09-18_at_12.45.14](/uploads/4f62e1e43238bfff4ec949cf407a1ff7/Screenshot_2023-09-18_at_12.45.14.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1428[ejpimport] Add ability to edit and/or format review data imported from DataHub2024-03-26T10:18:39ZRyan Dix-Peek[ejpimport] Add ability to edit and/or format review data imported from DataHubDocMaps contains review data. This review data is imported as plain text into Kotahi. This data is also stored as review data. Currently, review data is not editable in Kotahi. Group administrators need to be able to apply formatting imp...DocMaps contains review data. This review data is imported as plain text into Kotahi. This data is also stored as review data. Currently, review data is not editable in Kotahi. Group administrators need to be able to apply formatting imported review content before publishing.
**Acceptance criteria;**
- [ ] Create Control panel>Reviews page. Title of tab; Reviews.
- [ ] Remove 'Completed Reviews' from the Control panel>Decision page, and display this section on the 'Reviews' page.
- [ ] Configuration>Control panel setting to enable editing submitted reviews; 'Editors can edit submitted reviews'.
- [ ] When the above checkbox is selected; editors should be able to edit submitted reviews using a basic Wax editor from the Control panel>Reviews>Completed Reviews>Show>modal
![Screenshot_2024-03-04_at_13.55.58](/uploads/2489309924edca0286db937f899a76da/Screenshot_2024-03-04_at_13.55.58.png)
Configuration page;
![Screenshot_2024-03-04_at_13.58.24](/uploads/07825c205c07e756aae5873afda5d6af/Screenshot_2024-03-04_at_13.58.24.png)
Control panel>Reviews>Completed Reviews;
![Screenshot_2024-02-21_at_11.43.43](/uploads/875c5cb2ddd9d623d24abf3660cb0112/Screenshot_2024-02-21_at_11.43.43.png)DocMaps pluginAlexandros GeorgantasAlexandros Georgantashttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1424Setup new default forms2024-01-23T12:03:24ZRyan Dix-PeekSetup new default formsUpdate the default forms for the [instance archetypes](https://docs.coko.foundation/s/e191b651-f18a-4551-ba71-a1a3f1fdf9dc), making it easier for new users to adopt a predefined workflow and associated data profile.
Instance archetypes...Update the default forms for the [instance archetypes](https://docs.coko.foundation/s/e191b651-f18a-4551-ba71-a1a3f1fdf9dc), making it easier for new users to adopt a predefined workflow and associated data profile.
Instance archetypes to update;
1. `aperture`
2. `colab`
3. `elife`
No need to update NCRC, because nothing has changed here (no enhancement work has been done).https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1421Refactor document storage2023-09-20T05:51:07ZBen WhitmoreRefactor document storageThe current way manuscripts and their versions (plus reviews, decisions etc) are stored in the DB is very inflexible and not well suited for storing document history or adding other types of document such as author proofing feedback. It ...The current way manuscripts and their versions (plus reviews, decisions etc) are stored in the DB is very inflexible and not well suited for storing document history or adding other types of document such as author proofing feedback. It also involves unnecessary duplication of code. I would like a more generic and flexible schema that permits different collections of documents and more fine-grained versioning:
![image](/uploads/268e39831388db5d496b6e9483c4144c/image.png)
- The `DocSet` is the top-level container: the thing that appears in the list on the Manuscripts page.
- It contains multiple separate `Doc`s, which include different major versions of the manuscript/preprint, plus reviews, summaries, decisions and other related items. One of these is the `mainDoc`, usually the latest version of the manuscript/preprint.
- We keep a set of `DocRelation`s that tell us e.g. doc B is a review of doc A, doc C is also a review of A, and doc D is a summary of B and C. The `context` can hold further information that may be of use for generating DOCMAPs etc.
- A `Doc` has multiple `DocVersion`s: these are not versions of record, but more fine-grained: the version I've just edited versus the version someone else edited 5 minutes ago. If I'm editing a document such as a review that I haven't yet submitted, `isPendingSubmission` will be true, and this version will remain private to me. Until a first version has been submitted, the doc won't exist as far as the client is concerned.
- The JSON `data` in the `DocVersion` will contain everything we currently store in `manuscript.meta` and `manuscript.submission`. We'll just keep a very basic title at the `DocSet` level for convenience.
For versioning, I'm thinking we should create a new version each time edits are made by a user who is different to the previous user who edited, _or_ if 5 minutes have elapsed since the previous edit (and `isPendingSubmission` isn't true).
**Refactoring steps**
1. (optional) We would benefit from more extensive integration tests covering the full standard workflows.
2. Make the submission form work the same as the decision and review forms: _all_ form data to be stored in the `submission` object, and `SupplementaryFiles` and `VisualAbstract` fields store file references within the form data.
3. I propose creating the graphql API for this structure _before we change the database schema_: it will obtain data from the existing schema and restructure it to mimic the new schema. We can keep both old and new APIs running in parallel and gradually port client code to use the new structure.
4. Once the old API is completely phased out, we can refactor the back-end and DB.
**Benefits**
- Submissions, reviews and decisions are treated the same, meaning we need only a single set of code to deal with all of these.
- New artifacts/document types, such as author proofing feedback, will be very easy to add.
- Publishing can become much simpler and more flexible, using simple mappings rather than specialised code to publish the various artifacts.
- Helps rationalise the confusing and error-prone system of manuscript versioning we currently have. Querying to get a doc will always return the most recent version, while prior versions of record can be obtained with a subquery.
- It distinguishes between submitted and unsubmitted data. With decisions and submissions we do this very poorly.
- It keeps all version information needed for auditing, diffing and rollback.
- Simplifies production of rich DOCMAPs.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1413Import progress modal displayed on incorrect archetype2023-09-11T12:51:33ZRyan Dix-PeekImport progress modal displayed on incorrect archetypeThe progress bar displays for imported manuscripts is incorrectly shown in the `aperture` archetype. This issue only seemed to appear on the v2.0.0 release, where an instance has groups using the `colab` and `ncrc` archetypes.
![image]...The progress bar displays for imported manuscripts is incorrectly shown in the `aperture` archetype. This issue only seemed to appear on the v2.0.0 release, where an instance has groups using the `colab` and `ncrc` archetypes.
![image](/uploads/51e08c1eee85e21ba74e9a126c93352c/image.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1411Reviewer assignment fails if email fails2023-09-11T04:01:29ZBen WhitmoreReviewer assignment fails if email failsWhen inviting a reviewer, if "Email notification" is checked but email is not configured, that user appears under "Reviewer Status" in the "Invited" column, but that user can't see the manuscript in the "To Review" tab of their dashboard...When inviting a reviewer, if "Email notification" is checked but email is not configured, that user appears under "Reviewer Status" in the "Invited" column, but that user can't see the manuscript in the "To Review" tab of their dashboard, and has no way of accepting or performing the review.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1406Share modal controls2023-12-13T09:45:17ZRyan Dix-PeekShare modal controlsSubmission, Review and/or Decision form field settings control which form data is shared with the Author and/or Reviwer on the Decision>Submit action.
The purpose of this task is to support editors by surfacing the 'share settings' on ...Submission, Review and/or Decision form field settings control which form data is shared with the Author and/or Reviwer on the Decision>Submit action.
The purpose of this task is to support editors by surfacing the 'share settings' on the submit action so that they are aware of what data is being shared, and with whom. Furthermore, this feature should allow for editors to change these settings.
Suggested solution;
- Display share settings per form field in a modal on the submit action
- The Editor should be able to edit settings per role and submit
- From the modal, on submit action, the data is shared with author and/or reviewer
Only Review and Decision form fields can be shared with the author and/or reviewers on the Dcecisoin>Submit action.
Decision form;
![Screenshot_2023-11-13_at_14.54.10](/uploads/fdb53bd8feb7e569818f349ff8f59d10/Screenshot_2023-11-13_at_14.54.10.png)
Form field share options;
![Screenshot_2023-11-13_at_14.59.07](/uploads/33ea641d0e8695f92d80c9ac1faf12af/Screenshot_2023-11-13_at_14.59.07.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1401Support for import of multiple preprint versions against the same DOI2023-09-07T03:32:28ZRyan Dix-PeekSupport for import of multiple preprint versions against the same DOIhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1394[Colab] Email template update2023-08-30T10:54:39ZRyan Dix-Peek[Colab] Email template update'Reviwer invitation content should be as per 'Email #3 Reviewer invitation'. This has somehow been reverted.
[Reference document](https://docs.google.com/document/d/1H5guf5gHdOPt79rOTksiaM99H_37_N2P/edit?usp=sharing&ouid=10365408771427...'Reviwer invitation content should be as per 'Email #3 Reviewer invitation'. This has somehow been reverted.
[Reference document](https://docs.google.com/document/d/1H5guf5gHdOPt79rOTksiaM99H_37_N2P/edit?usp=sharing&ouid=103654087714276915531&rtpof=true&sd=true)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1393[Colab] Submission duplicated2023-08-25T05:27:05ZRyan Dix-Peek[Colab] Submission duplicatedTwo submissions were created on a single submit 'new URL submission' action; 9750, 9749
![Screenshot_2023-08-25_at_07.26.51](/uploads/3cd549206f3ee2f8f871bedd11c4010c/Screenshot_2023-08-25_at_07.26.51.png)Two submissions were created on a single submit 'new URL submission' action; 9750, 9749
![Screenshot_2023-08-25_at_07.26.51](/uploads/3cd549206f3ee2f8f871bedd11c4010c/Screenshot_2023-08-25_at_07.26.51.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1392Clean up .env variables, migrations and group types2023-08-25T02:46:14ZBen WhitmoreClean up .env variables, migrations and group typesAfter the 2.0.0 release, we have a lot of .env variables that are no longer in use, and should be removed from docker-compose files, config code, `.env.example`, and documentation.
We also should rename the current group types 'aperture...After the 2.0.0 release, we have a lot of .env variables that are no longer in use, and should be removed from docker-compose files, config code, `.env.example`, and documentation.
We also should rename the current group types 'aperture', 'colab', 'elife' and 'ncrc' to (respectively) 'journal', 'prc', 'single_form' and ??.
By removing the .env variables we will prevent some older migrations from running, so we should also take the opportunity to replace all pre-2.0 migrations with a single, simplified migration for each table. These simplified migrations should each be written so as to not replace existing data, or else should use an existing migration name so they won't get rerun on existing installations. E.g. there are currently 20 migrations for the `manuscripts` table, and these could be simplified to a single migration named `1581450834-manuscript.sql` (the same name/timestamp as the earliest of the current migrations).
Tables (and Objection.js model schemas) in some cases retain columns that aren't used, either to support old migrations or to allow rollback, and there are some redundant tables such as `files_old`. All of this could be cleaned up.
CHANGES.md must include instructions that in order to upgrade from 1.x to 2.x you must upgrade to 2.0.0 as an intermediate step.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1386EPP articles accessible from Flax article list2023-08-30T09:40:47ZRyan Dix-PeekEPP articles accessible from Flax article listThe purpose of this task is to allow eLife's enhanced preprint website to be accessible when clicking on the article link from the article list in Flax.
**References;**
- Colab publishing endpoint requirements; https://docs.google.com/s...The purpose of this task is to allow eLife's enhanced preprint website to be accessible when clicking on the article link from the article list in Flax.
**References;**
- Colab publishing endpoint requirements; https://docs.google.com/spreadsheets/d/1xwsWw14YxnC2gP2BaGVIogNLqD6ZziY23nIk--p0nc8/edit?pli=1#gid=0
- Access all EPP DocMap can be retrieved from; https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/index
- Example DocMap; https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=85111CMS v2https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1374[CMS] Store published manuscript record2023-08-09T10:12:14ZRyan Dix-Peek[CMS] Store published manuscript recordCurrently, publish action (from CMS>Pages & Control panel>Decision) rebuilds all published webpages (webpages and article pages) in Flax. Ideally, we'll look at separating publishing actions for publishing CMS webpage and article content.Currently, publish action (from CMS>Pages & Control panel>Decision) rebuilds all published webpages (webpages and article pages) in Flax. Ideally, we'll look at separating publishing actions for publishing CMS webpage and article content.