Kotahi issueshttps://gitlab.coko.foundation/kotahi/kotahi/-/issues2024-03-22T12:47:16Zhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1552Expose CMS files2024-03-22T12:47:16ZRyan Dix-PeekExpose CMS filesExpose CMS files in CMS>Files.MR; https://gitlab.coko.foundation/kotahi/kotahi/-/merge_requests/1111Expose CMS files in CMS>Files.MR; https://gitlab.coko.foundation/kotahi/kotahi/-/merge_requests/1111Giannis Kopanasjkopanas@gmail.comGiannis Kopanasjkopanas@gmail.comhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/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/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/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/1526Unable to save special parsing/formatting form field settings2024-03-15T10:42:03ZRyan Dix-PeekUnable to save special parsing/formatting form field settingsGroup Managers can apply a Special parsing/formatting form field setting, but clicking on 'update' does not save the selection. There is also a selection option 'None' - this seems redundant, the only selection options should be Special ...Group Managers can apply a Special parsing/formatting form field setting, but clicking on 'update' does not save the selection. There is also a selection option 'None' - this seems redundant, the only selection options should be Special prasing>Split at comma and Special fomratting>Join at commas. 'None' should be null or the default value when Split at comma/Join at commas. have not been selected.
![Screenshot_2024-02-12_at_08.48.31](/uploads/a5917212430aaa3357dee09ffb2b50af/Screenshot_2024-02-12_at_08.48.31.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/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/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/1495One Minute Migrations integrations2024-03-13T10:15:23ZAdam Hydeadam@coko.foundationOne Minute Migrations integrationsWe need to implement a service that starts the one min migrations. It is a beta functionn. See video https://vimeo.com/831331602We need to implement a service that starts the one min migrations. It is a beta functionn. See video https://vimeo.com/831331602v3.1.0Vukile LangaVukile Langahttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1540[BPSC] Edit Collaborative form field data from the Control panel2024-03-12T09:34:31ZRyan Dix-Peek[BPSC] Edit Collaborative form field data from the Control panelThe purpose of the task is to allow editors to access and edit content saved in a Collaborative form field.
**Workflow overview**
PEER REVIEW
1. Trainee Reviewer reads the paper.
1. Trainee Reviewer drafts a review.
1. Trainee Reviewe...The purpose of the task is to allow editors to access and edit content saved in a Collaborative form field.
**Workflow overview**
PEER REVIEW
1. Trainee Reviewer reads the paper.
1. Trainee Reviewer drafts a review.
1. Trainee Reviewer messages Expert Reviewer that draft is ready for review.
1. Expert Reviewer reviews and makes suggestions.
1. Expert Reviewer notifies the Trainee Reviewer that the review needs edits.
1. Trainee Reviewer revises review (returns to step 5).
1. Expert Reviewer hands review over to Editor.
EDITORIAL REVIEW
1. Editor reviews.
1. Editor makes changes
1. If the review needs more work, the editor adds comments for the reviewers and notifies the Trainee Reviewer and Expert Reviewer of the need for edits. (Return to step 5 above).
1. Editor adds comments to reviewers and submits.
The solution;
- Reviewers will be assigned a 'collaborative' state on invite action.
- Collaborative reviewers will see the same Review form fields, and non-collaborative reviewers will access their own Review form on the `/review` page.
- Completed and Collaborative reviews will be displayed on the Control panel>Review page (see #1428).
- For collaborative reviews, editors will be able to control edit access to the Review page using a locking/unlocking control. A 'locked' Review page will still be accessible in a read-only state.
**Acceptance criteria;**
- [ ] Add checkbox to the 'Invite Reviewer' modal; 'Collaborate'. Update 'Shared' text; 'Read other submitted reviews'
- [ ] 'Collaborative Reviews' will be displayed on the Control panel>Review tab under a section below 'Submitted Reviews' - if there are no collaborative reviews, then the section should be hidden.
- [ ] The editor can lock collaborative form fields, which will allow collaborative reviewers read-only access on the Review page, or unlock allowing collaborative reviewers edit access to the Review page. Display a [lock](https://feathericons.com/?query=lock) or [unlock](https://feathericons.com/?query=unlock) on the Control panel>Revies>Collaborative Reviews card (TBC).
- [ ] The editor can always access and edit content within the current version. When a new version of the manuscript is created, the content of the collapsable form field is read-only.BPSC Collaborative form field typeGiannis Kopanasjkopanas@gmail.comGiannis Kopanasjkopanas@gmail.comhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1543title tags need to encode marks correctly2024-03-07T18:31:43ZCloud68 Support teamtitle tags need to encode marks correctlyIn this example, headers have bold and italic in them. When exported to JATS, the `<strong>` and `<em>` are not encoded correctly, and we get something like this:
```
<title>Commentaries on &lt;em&gt;Nanothermodynamics&lt;/em&gt;</title...In this example, headers have bold and italic in them. When exported to JATS, the `<strong>` and `<em>` are not encoded correctly, and we get something like this:
```
<title>Commentaries on <em>Nanothermodynamics</em></title>
```
which should be
```
<title>Commentaries on <italic>Nanothermodynamics</italic></title>
```
The unescaped ampersands cause the XML to be invalid to the parser. We need to process these marks correctly.
---
(previous report:)
<!-- Required. Provide a general summary of the issue in the title above -->
## Expected behavior
When trying to download JATS on production an error will be shown mentioning that the JATS is invalid.
the following log is from console
```
Error making JATS. Errors: {"err":{"code":"InvalidChar","msg":"char '&' is not expected.","line":1,"col":20441}}
```
no errors are shown on the container logs
<!-- Required. Tell us what should happen -->
## Current behaviour
<!-- Required. Tell us what happens instead of the expected behaviour -->
## Steps to reproduce
<!-- Required. Provide a link to a live example or screenshots, and the steps to reproduce this bug.]-->
1. create a new manuscript
2. add your data
3. submit it
4. go to production
5. download JATS
6. get a link but the error of invalid JATS is shown
## Environment
<!-- Required. Provide relevant information such as browser name and version, PC or Mac use, internet speed, etc.]-->
## Possible solution
<!-- If known, provide details on how to fix the bug.-->
<!-- After creating this issue you can link other related or blocking issues with the Gitlab's Linked issues functionality. -->Dan ViselDan Viselhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/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/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/1544Update of SQL dumps used for cypress testing2024-03-01T13:44:32ZSidorela UkuUpdate of SQL dumps used for cypress testingSince the last update of the dump files, some fields in the db have changed or are added new. And this impact the result of the tests output to not match the current development status.
There few cases in review that should have failed ...Since the last update of the dump files, some fields in the db have changed or are added new. And this impact the result of the tests output to not match the current development status.
There few cases in review that should have failed but they still are successful, considering that issue #1504 is not yet implemented.
I will open a new MR to follow up with the updates in the dump files used for the automated testing.Sidorela UkuSidorela Ukuhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1483[BPSC] Create full wax editor form field type2024-02-29T10:52:54ZRyan Dix-Peek[BPSC] Create full wax editor form field typeThe purpose of the collaborative editor is to support multiple users accessing and editing the same review content. For the MVP, only reviewers assigned to a review will be able to access this collaborative form field form the Review pag...The purpose of the collaborative editor is to support multiple users accessing and editing the same review content. For the MVP, only reviewers assigned to a review will be able to access this collaborative form field form the Review page, and editors assigned to a manuscript will be able to access the field from the control panel.
**Acceptance criteria;**
- [ ] This task aims to create a new form field type; Collaborative editor. A Group Manager should be able to select and add this field to a Review form.
- [ ] The collaborative editor will use a full wax editor. Production tools; Download, Annotations and Parsers should not be displayed.BPSC Collaborative form field typeGiannis Kopanasjkopanas@gmail.comGiannis Kopanasjkopanas@gmail.comhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1546Suggested changes and comments not dispayed to authors across versions2024-02-29T06:16:04ZRyan Dix-PeekSuggested changes and comments not dispayed to authors across versionsAfter creating a new version, when accessing the Manuscripts page, authors cannot see suggested changes/comment annotations.
## Expected behaviour
Authors should be able to see track changes/Comments annotations on the Manuscripts text...After creating a new version, when accessing the Manuscripts page, authors cannot see suggested changes/comment annotations.
## Expected behaviour
Authors should be able to see track changes/Comments annotations on the Manuscripts text page.
## Current behaviour
For a traditional publishing workflow, when editing manuscripts in Wax; authors can see suggested changes inline, but not the annotations or comments when accessing the content from the `/submit`> Manuscripts.
## Steps to reproduce
1. Author submits docx
2. Group Manager adds suggested changes/comments in Production editor
3. Editor/Group Manager set Decision to 'revise' and submits
4. Author creates a new version
5. Author access Manuscripts text page - can see inline track changes but not the annotations
## Environment
Persists on v3.0.2
![Screenshot_2024-02-29_at_07.35.57](/uploads/b5646eda330fc238c8900c1ec99655fa/Screenshot_2024-02-29_at_07.35.57.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1537[BPSC] Metadata missing from imported manuscripts2024-02-28T06:35:16ZRyan Dix-Peek[BPSC] Metadata missing from imported manuscriptsMetadata missing from imported preprints/articles; Title, DOI, Abstract, Link
I suspect this may be due to the updates made to the form builder and the associated mapping.
![Screenshot_2024-02-20_at_05.59.16](/uploads/4222cf96ebacbbd...Metadata missing from imported preprints/articles; Title, DOI, Abstract, Link
I suspect this may be due to the updates made to the form builder and the associated mapping.
![Screenshot_2024-02-20_at_05.59.16](/uploads/4222cf96ebacbbd2e485dcfe2ca2257a/Screenshot_2024-02-20_at_05.59.16.png)
![Screenshot_2024-02-20_at_06.00.11](/uploads/b0aa97b5fb619f5ca772c1eb113b39e3/Screenshot_2024-02-20_at_06.00.11.png)BPSC Collaborative form field typehttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1542Folmulas not being formated correctly on the html export2024-02-22T10:20:33ZCloud68 Support teamFolmulas not being formated correctly on the html export<!-- Required. Provide a general summary of the issue in the title above -->
## Expected behaviour
<!-- Required. Tell us what should happen -->
## Current behavior
<!-- Required. Tell us what happens instead of the expected behaviou...<!-- Required. Provide a general summary of the issue in the title above -->
## Expected behaviour
<!-- Required. Tell us what should happen -->
## Current behavior
<!-- Required. Tell us what happens instead of the expected behaviour -->
When downloading an HTML from a manuscript the formulas on it will not be formatted correctly, they are displayed as they are written on the manuscript.
## Steps to reproduce
<!-- Required. Provide a link to a live example or screenshots, and the steps to reproduce this bug.]-->
1. create a new manuscript
2. publish it
3. try to download a html version of it
4. you will get a html with not formatted formulas
## Environment
<!-- Required. Provide relevant information such as browser name and version, PC or Mac use, internet speed, etc.]-->
## Possible solution
<!-- If known, provide details on how to fix the bug.-->
<!-- After creating this issue you can link other related or blocking issues with the Gitlab's Linked issues functionality. -->https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1407[CoLab] Display form field publishing settings & endpoints on Publish action2024-02-21T06:00:29ZRyan Dix-Peek[CoLab] Display form field publishing settings & endpoints on Publish actionThis task allows the editor to see and confirm what data will be shared publicly when publishing from the Control panel>Decision page.
Solution;
- When clicking on the Decision>Decision>Publish button, editors will be presented with a...This task allows the editor to see and confirm what data will be shared publicly when publishing from the Control panel>Decision page.
Solution;
- When clicking on the Decision>Decision>Publish button, editors will be presented with a modal providing a summary of each form field that will be published, and to which endpoint; Webhook, Hypothesis, Flax and/or Crossref.
- The editor will have the option to alter the settings from this modal.
- The editor will be able to publish metadata, manuscripts, reviews and/or decision data when clicking on the submit action displayed in the modal.
UI; TBC
**Acceptance criteria;**
- [ ] Editors and Group Managers can enable/disable publishing Manuscripts, Submission, Review and/or Decision form field data to Flax, Hypothesis, Webhook, Crossref and/or other endpoints from the Control panel>Deicsion>Decision>Submit>Submit modal.
![Screenshot_2023-12-13_at_14.15.31](/uploads/43bdad5cf69a10bda9c3dd43e6c17c4d/Screenshot_2023-12-13_at_14.15.31.png)CoLab Biophysics v6