Kotahi issueshttps://gitlab.coko.foundation/kotahi/kotahi/-/issues2023-12-22T07:09:39Zhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1491Image, figures, and tables in Wax2023-12-22T07:09:39Zjulientaqjulien@coko.foundationImage, figures, and tables in WaxLooking at Pooyan and elife articles, the captions for tables and images we have right now in Kotahi don’t offer enough options, and they have a different behaviors.
We need to make it easier for the user to manage the captions for tabl...Looking at Pooyan and elife articles, the captions for tables and images we have right now in Kotahi don’t offer enough options, and they have a different behaviors.
We need to make it easier for the user to manage the captions for tables and images.
1. The UI to add title and caption for table is quite different from the images, but both forbid any complex caption.
This is how a figure caption looks like in Kotahi.
![Screenshot_2023-12-21_at_12.06.47](/uploads/2e5afd4806ab14a5532456bbfae02b26/Screenshot_2023-12-21_at_12.06.47.jpg)
And this is how a text caption exists:
![Screenshot_2023-12-21_at_12.09.55](/uploads/430bb51c3bf8530dbd895c90ce8b8f4e/Screenshot_2023-12-21_at_12.09.55.jpg)
They need to be the same, as the type of metadata they need is quite close.
2. We need to be able to add title, list, paragraphs, or any other block level type of content in the caption. Right now, we can only have simple text.
Adding a table should work as adding a image and it should offer the option to add custom label, title, long caption and alt text (for images).
Both can be put inside a `figure` element.
---
Last thing, sometimes, the images and the tables are not figure but part of the flow (it happens sometimes in elife’s epp manuscript).
In that case, we should be able to define that in wax.
Attaching a couple of pdf/images to show some examples:
![Screenshot_2023-12-21_at_12.36.43](/uploads/b5f5b36533b0b1d6bff9e921b19f906a/Screenshot_2023-12-21_at_12.36.43.jpg)
![Screenshot_2023-12-21_at_12.37.26](/uploads/42f34596e624490bddc6b08e33bf7e1a/Screenshot_2023-12-21_at_12.37.26.jpg)
![Screenshot_2023-12-21_at_12.38.04](/uploads/714638bd6283d6203e82015a4cfb4f5b/Screenshot_2023-12-21_at_12.38.04.jpg)
[elife examples are coming from Bioarxiv so their tables are actually images, but the problem would be the same with real `table` elements.]https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1490XSweet: New Approach2024-01-29T11:55:10ZMurali KasiramanXSweet: New ApproachXSweet does both normalization as well as font based style identification. We need to separate both these services as independent services.
1. Normalization (Clean-up, font normalization, junk characters, etc.)
2. Style identification
B...XSweet does both normalization as well as font based style identification. We need to separate both these services as independent services.
1. Normalization (Clean-up, font normalization, junk characters, etc.)
2. Style identification
Because of this synchronized activity, we are getting issues like block inside block, and other issues that are unnoticed as of now:
Example:-
<h4><math-display class=”math-node”>....</math-display>{{some content}}</h4>
This results in non-rendering of math tags in the editor due to block scoped schema.
We also find the following issues in Xsweet in terms of LaTex:
1. math-display comes inside table cell
example :- <td><p class=”paragraph”><math-display class=”math-node”> \\mu</math-display></p><td>
2. Missing closing tags for \left:-
Xsweet latex:
\left(7\right)p\left(1\right)=\theta _{y}\varphi \left(\frac{1-\mu }{\mu }
Corrected latex: -
\left(7\right)p\left(1\right) = \theta_{y} \varphi\left(\frac{1-\mu}{\mu}\right)
3. Unwanted closing tags:-
Xsweet latex:-
\dot {\iota }=\beta _{\iota }\cdot (\iota ^{T}-\iota \right)
Corrected latex:-
\dot {\iota }=\beta _{\iota }\cdot (\iota ^{T}-\iota)
4. Fraction correction:-
Xsweet latex:-
\sfrac{1}{2}https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1477Load testing2024-02-15T06:33:52ZRyan Dix-PeekLoad testingThe Amnet team have requested an evaluation to determine system performance specifications; https://docs.google.com/document/d/1NPyo5mI7z4agXvxRO6DHwCR-8wygBMZgarpc4h1OFQ8/edit?usp=sharing
To evaluate performance specifications for Kota...The Amnet team have requested an evaluation to determine system performance specifications; https://docs.google.com/document/d/1NPyo5mI7z4agXvxRO6DHwCR-8wygBMZgarpc4h1OFQ8/edit?usp=sharing
To evaluate performance specifications for Kotahi we implement the following;
1. Turn database logging on and test queries to establish impact.
2. Create a Cypress test to run 'high load' queries simulating rapid interactions by multiple users.
3. Run an Amazon server using predefined standards to establish minimum memory requirements and other details.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1476pdf export2023-12-10T22:40:07Zjulientaqjulien@coko.foundationpdf exportIf you use a javascript file with two `.` in the name, the rendering gets broken.
```
qrcode.min.js
```
needs to be renamed
```
qrcode.js
```
so the export can run.
We should use the extension name of any file we uploadIf you use a javascript file with two `.` in the name, the rendering gets broken.
```
qrcode.min.js
```
needs to be renamed
```
qrcode.js
```
so the export can run.
We should use the extension name of any file we uploadhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1475Error when accessing 'view' from manuscripts page as admin2023-12-08T04:34:14ZAdam Hydeadam@coko.foundationError when accessing 'view' from manuscripts page as adminTypeError: Cannot read properties of undefined (reading 'updateChannelViewed') at yI (app.c5a8145d.js:377358:1) at Go (app.c5a8145d.js:251028:1) at gs (app.c5a8145d.js:251028:1) at cl (app.c5a8145d.js:251028:1) at sl (app.c5a8145d.js:251...TypeError: Cannot read properties of undefined (reading 'updateChannelViewed') at yI (app.c5a8145d.js:377358:1) at Go (app.c5a8145d.js:251028:1) at gs (app.c5a8145d.js:251028:1) at cl (app.c5a8145d.js:251028:1) at sl (app.c5a8145d.js:251028:1) at $s (app.c5a8145d.js:251028:1) at app.c5a8145d.js:251028:1 at t.unstable_runWithPriority (app.c5a8145d.js:251336:1) at Fi (app.c5a8145d.js:251028:1) at Wi (app.c5a8145d.js:251028:1)
when trying to access view from the manuscripts page for article 29990 on kotahidev @ryandixpeekhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1474PDF template: show classes and ID used in the article2023-12-07T04:42:44Zjulientaqjulien@coko.foundationPDF template: show classes and ID used in the articleWhen making a template in Kotahi, there is no way to know the different `class` and `id` used in the content of the article.
For example. the abstract is exported as `abstractSection`. If you don’t have that information you can’t make a...When making a template in Kotahi, there is no way to know the different `class` and `id` used in the content of the article.
For example. the abstract is exported as `abstractSection`. If you don’t have that information you can’t make a template.
We need table showing all the semantics available in the editor and their corresponding output to be able to style them correctly.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1467Publisher[s] on single domain across journals2024-01-31T09:53:14ZsathishkumarbPublisher[s] on single domain across journals
# RFC: Feature proposal: Publisher[s] on single domain across journals
## Context
The purpose of this specification is to outline the requirements and behavior of the publisher login and redirect functionality on the Kotahi platform. ...
# RFC: Feature proposal: Publisher[s] on single domain across journals
## Context
The purpose of this specification is to outline the requirements and behavior of the publisher login and redirect functionality on the Kotahi platform. The primary aim is to empower a super admin to efficiently manage multiple journals through a unified URL. The proposed solution includes a comprehensive user interface for adding, editing, and managing publishers, all within a single URL. This enhancement will empower super admins to oversee journals comprehensively and provide publishers access to consolidated reports.
## Proposal
Objectives:
Unified Access:
Enable the super admin to access and manage all journals through a single domain URL.
Admin Interface Enhancement:
Develop a user-friendly super admin interface for seamless management of publishers.
Provide functionalities for adding, editing, and managing publishers within the same interface.
Streamlined Journal Administration:
Allow the super admin to perform actions such as adding, editing, and managing publishers in a unified environment.
Comprehensive Reporting:
Introduce a reporting feature within the super admin interface.
Allow publishers to access consolidated reports for all journals through their super admin login.
Scope:
Publisher[s] must be able to visit their journal[s] in the same domain URL. Admin interface must be provided to manage the publishers, and then they should be able to configure publishers to the journals and it follows many to many relationship model.
Ex:
Publisher A -> Journal
Publisher B -> Journal1
Publisher B -> Journal2
Publisher C -> Journal
User Interface:
The user interface of the publisher and configuring publishers to the journals are followed as below:
a. Add/Edit/Delete Publisher
delete won't be possible, if journals are mapped/configured to the publisher
b. Manage add/edit/remove journals(archetype) from the list to the publisher
Single URL Management:
Enable the super admin to perform all necessary actions related to publishers and journals within a single URL.
Publisher Management:
Provide options for adding, editing, and managing publishers efficiently.
Unified Control Panel:
Design a cohesive control panel allowing the super admin to oversee and control all aspects of multiple journals from a centralized location.
Reporting Section:
Implement a reporting section within the super admin interface for publishers to access consolidated reports across all journals.
## Design
[Include sketch or wireframes of the UI changes necessary for this feature]
## Implementation (if applicable)
[A description of the steps to implement the feature.]
## Alternative approaches (if applicable)
[Include any alternatives to meet this use case.]
## Open issues (if applicable)
[Links to and a discussion of related issues, if applicable.]https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1462Dev Notes2023-11-20T03:51:20ZAdam Hydeadam@coko.foundationDev NotesMaking these dev notes for potential discussion:
1. CMS
1. edit article template
2. multiple article templates depennding on article type
3. unpublish article
4. SEO
5. link to PDF & JATS
6. nested menu
...Making these dev notes for potential discussion:
1. CMS
1. edit article template
2. multiple article templates depennding on article type
3. unpublish article
4. SEO
5. link to PDF & JATS
6. nested menu
7. improve Pagedjs production UI
8. render preview
9. version templates/CSS
10. expose tree
2. Production tasks
3. Task inter-dependencies
4. Add editors to new submissions determined by article type
5. CRediT Taxonomy
6. ROR Taxonomy
7. MECA export
8. Submission form keywords taxonomy
9. Adding suggested reviewers by author to review process
10. Adding automated suggested reviewers
11. Personalising emails
12. Multiple revision email templates
13. Support file attachments to outgoing emails
14. Email author-\> editorial staff for help
15. Different reviewer forms depending on article type
16. Assigning reviewers to a group of submissions
17. Declining reviewers can suggest another reviewer
18. Author and staff availability cal
19. Export events to CSVhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1461Releases Announcement and General Maintenance etc Announcement banner2024-01-10T08:16:26ZAdam Hydeadam@coko.foundationReleases Announcement and General Maintenance etc Announcement bannerWe need to work out how to
1. announce to kotahi admins that there is a new version of Kotahi released and what the new features are
2. maintenance forward-announcements to all users
3. general announcements to all users
First we start...We need to work out how to
1. announce to kotahi admins that there is a new version of Kotahi released and what the new features are
2. maintenance forward-announcements to all users
3. general announcements to all users
First we start with something very basic.
The ability to make announcements should be a new item in the left pane under Emails and labeled 'announce'. On that (new) page we see:
1. a basic textfield (we could use wax but probably the easiest is if we use plain text announcements for now)
2. an 'announce now!' button
3. a 'don't display any announcements' checkbox
Announcements get displayed on the user dashboard as an overlay that can be clicked away. Once a specific announcement is clicked away it does not appear again for the user. The dashboard item on the left of the nav menu should display a indicator to suggest there is an announcement to be read on the dashboard.
There is just one kind of announcement, later we will add:
* wax editor
* rich text display of announcements
* color selector for the background of an announcement to reflect the announcement type (eg warning, general announcement etc)
* setting color and some defaults for different types of announcement templates
Announcements (for now) are displayed in plain text against a white background (bordered)Ryan Dix-PeekRyan Dix-Peekhttps://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/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)