Kotahi issueshttps://gitlab.coko.foundation/kotahi/kotahi/-/issues2023-09-25T07:49:53Zhttps://gitlab.coko.foundation/kotahi/kotahi/-/issues/1426Editing citations in the full wax editor2023-09-25T07:49:53ZRyan Dix-PeekEditing citations in the full wax editorThis task impacts the author proofing workflow and is only applicable after the release of the Citation Manager. We assume production workflow will result in parsed citations being displayed in the full wax editor accessed by authors fr...This task impacts the author proofing workflow and is only applicable after the release of the Citation Manager. We assume production workflow will result in parsed citations being displayed in the full wax editor accessed by authors from the `/submission` page.
When accessing the editor, authors should be able to;
- Read parsed citations
- Add a new citation within a paragraph
- Add new citations to a reference list
- Edit existing citations (using the Citation Manager edit modal)
- Delete a citation
For the author-proofing workflow, these changes should be displayed as 'suggested changes' in Wax.Amnet Wax citation packageshttps://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/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 v6https://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/1389[BPSC] Setup publishing to Hypothe.is2023-08-21T09:27:17ZRyan Dix-Peek[BPSC] Setup publishing to Hypothe.is1. Create a new Hypothe.is group
2. input credentials in Configuration>Hypothe.is1. Create a new Hypothe.is group
2. input credentials in Configuration>Hypothe.isSetup Bat Pathogen Spillover Compendium instancehttps://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.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1369DOAJ Indexing2023-11-22T12:30:20ZRavindhar RangarajanDOAJ Indexing**1. Introduction**
Nvcleus Publishing Platform seeks to promote open access and increased visibility of its scholarly articles by indexing them on the Directory of Open Access Journals (DOAJ). This specification document outlines the pr...**1. Introduction**
Nvcleus Publishing Platform seeks to promote open access and increased visibility of its scholarly articles by indexing them on the Directory of Open Access Journals (DOAJ). This specification document outlines the process of registering a publisher account on DOAJ and the procedure to submit articles using the existing CrossRef schema or by structuring the XML in a specific format.
**Reference Links:**
https://doaj.org/docs/faq/
https://doaj.org/api/v3/docs
https://www.crossref.org/documentation/schema-library/xsd-schema-quick-reference/
https://doaj.org/docs/xml/#example-doaj-xml-file
**2. Registering a Publisher Account on DOAJ**
To begin indexing articles on DOAJ, Nvcleus Publishing Platform must first register a publisher account using the following link: https://doaj.org/publisher/
**3. CrossRef Schema for Article Submission**
The Nvcleus Journals Platform already utilizes the CrossRef schema for registering its journals (contact Ravindhar for more info); it can use the same schema to submit articles to DOAJ. The CrossRef schema includes essential metadata fields such as DOI, title, authors, affiliations, abstract, full-text URL, and keywords.
**4. Structuring XML for Article Submission**
If Nvcleus Publishing Platform does not use the CrossRef schema, articles can be submitted to DOAJ by structuring the XML in the format provided below:
```
<?xml version="1.0" encoding="UTF-8"?>
<records>
<record>
<language>[Language]</language>
<publisher>[Publisher Name]</publisher>
<journalTitle>[Journal Title]</journalTitle>
<issn>[Print ISSN]</issn>
<eissn>[Electronic ISSN]</eissn>
<publicationDate>[Publication Date - YYYY-MM-DD]</publicationDate>
<volume>[Volume Number]</volume>
<issue>[Issue Number]</issue>
<startPage>[Start Page]</startPage>
<endPage>[End Page]</endPage>
<doi>[DOI]</doi>
<publisherRecordId>[Publisher Record ID]</publisherRecordId>
<documentType>[Document Type - e.g., article]</documentType>
<title language="[Language]">[Article Title]</title>
<authors>
<author>
<name>[Author Name]</name>
<affiliationId>[Affiliation ID]</affiliationId>
<orcid_id>[ORCID ID]</orcid_id>
</author>
<!-- Additional authors, if applicable -->
</authors>
<affiliationsList>
<affiliationName affiliationId="[Affiliation ID]">[Affiliation Name]</affiliationName>
<!-- Additional affiliations, if applicable -->
</affiliationsList>
<abstract language="[Language]">[Abstract Text]</abstract>
<fullTextUrl format="[File Format]">[Full Text URL]</fullTextUrl>
<keywords language="[Language]">
<keyword>[Keyword 1]</keyword>
<keyword>[Keyword 2]</keyword>
<!-- Additional keywords, if applicable -->
</keywords>
</record>
<!-- Additional records for other articles, if applicable -->
</records>
```
**5. XML Elements Explanation**
[Language]: Language code of the article (e.g., "eng" for English).
[Publisher Name]: Name of the publishing platform (Nvcleus Publishing Platform).
[Journal Title]: Title of the journal in which the article is published.
[Print ISSN]: Print ISSN of the journal.
[Electronic ISSN]: Electronic ISSN of the journal.
[Publication Date - YYYY-MM-DD]: Publication date of the article in the format "YYYY-MM-DD".
[Volume Number]: Volume number of the journal.
[Issue Number]: Issue number of the journal.
[Start Page]: Starting page number of the article in the journal.
[End Page]: Ending page number of the article in the journal.
[DOI]: Digital Object Identifier of the article.
[Publisher Record ID]: Unique record identifier used by the publisher.
[Document Type]: Type of the document, e.g., "article".
[Article Title]: Title of the article.
[Author Name]: Name of the article's author.
[Affiliation ID]: Unique ID for the author's affiliation.
[ORCID ID]: ORCID ID of the author (if available).
[Abstract Text]: Abstract of the article.
[File Format]: Format of the full text file (e.g., "pdf").
[Full Text URL]: URL to access the full text of the article.
**6: Obtain API Credentials**
To use the DOAJ API, you need to obtain API credentials, which typically include an API key or an access token. You can request these credentials by registering as a publisher on DOAJ and obtaining API access.
More detailed information on this link: https://doaj.org/api/v3/docs
**6. Article Submission Process**
Once the XML file is structured according to the provided format, Nvcleus Publishing Platform can submit to the DOAJ using the API.
**Example API call: **
Assuming you have obtained your API key and saved your article metadata in an XML file called article.xml, you can use cURL to make the API request as follows:
`curl -X POST -H "Content-Type: application/xml" -H "Authorization: API_KEY_YOUR_API_KEY" --data-binary "@article.xml" `https://doaj.org/api/v1/articles/
Replace YOUR_API_KEY with your actual API key.
**7. Conclusion**
By adhering to the specifications provided in this document, Nvcleus Publishing Platform can effectively index its articles on the Directory of Open Access Journals (DOAJ), ensuring increased visibility and accessibility of scholarly content to the global research community. Proper indexing on DOAJ contributes to the promotion of open access and the dissemination of valuable research publications.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1368Google Scholar Indexing - HTML output2023-11-22T12:30:18ZRavindhar RangarajanGoogle Scholar Indexing - HTML output**1. Introduction**
Nvcleus Publishing Platform is a web-based platform that allows users to publish academic journals and books directly onto the website. To ensure proper indexing and visibility on search engines, including Google Sch...**1. Introduction**
Nvcleus Publishing Platform is a web-based platform that allows users to publish academic journals and books directly onto the website. To ensure proper indexing and visibility on search engines, including Google Scholar, we need to structure the HTML meta tags in a specific way. This specification document outlines the required meta tags and their structure for effective indexing on Google Scholar.
**Reference Links:**
https://docs.pkp.sfu.ca/google-scholar/en/#introduction
https://scholar.google.com/intl/en/scholar/inclusion.html#indexing
**2. Meta Tag Structure**
The following are the meta tags that should be structured within the HTML code of each published article or book:
**2.1. Title of the Publication**
`<meta name="citation_title" content="[Publication Title]">`
Replace [Publication Title] with the actual title of the article or book.
**2.2. Authors**
`<meta name="citation_author" content="[Author Name]">`
Include one tag for each author of the publication. Replace [Author Name] with the full name of the author.
**2.3. Publication Date**
`<meta name="citation_publication_date" content="[YYYY/MM/DD]">`
Replace [YYYY/MM/DD] with the publication date of the article or book in the format year/month/day (e.g., 1996/05/17).
**2.4. Journal Title (for Journals)**
`<meta name="citation_journal_title" content="[Journal Title]">`
Replace [Journal Title] with the title of the journal in which the article was published. This tag is not needed for books.
**2.5. Volume (for Journals)**
`<meta name="citation_volume" content="[Volume Number]">`
Replace [Volume Number] with the volume number of the journal. This tag is not needed for books.
**2.6. Issue (for Journals)**
`<meta name="citation_issue" content="[Issue Number]">`
Replace [Issue Number] with the issue number of the journal. This tag is not needed for books.
**2.7. First Page and Last Page (for Journals)**
```
<meta name="citation_firstpage" content="[First Page Number]">
<meta name="citation_lastpage" content="[Last Page Number]">
```
Replace [First Page Number] and [Last Page Number] with the respective page numbers of the article in the journal. These tags are not needed for books.
**2.8. PDF URL**
`<meta name="citation_pdf_url" content="[URL to PDF]">`
Replace [URL to PDF] with the direct URL to the full PDF version of the article or book.
**2.9. Marking the references**
Mark the section of the paper that contains references to other works with a standard heading, such as "References" or "Bibliography", on a line just by itself. Individual references inside this section should be either numbered "1. - 2. - 3." or "[1] - [2] - [3]" in PDF, or put inside an "<ol>" list in HTML. The text of each reference must be a formal bibliographic citation in a commonly used format, without free-form commentary.
Please understand that the references are identified automatically by the parser software; they're not entered or corrected by human operators. While we try to support the most common reference formats, it is not possible to guarantee that all references are identified correctly; and incorrect identification of references could lead to exclusion of your papers from Google Scholar or to low ranking of your papers in the search results.
**3. Usage Example**
Here's an example of how the meta tags should be implemented in the HTML code of a published article:
```
<head>
<meta name="citation_title" content="The testis isoform of the phosphorylase kinase catalytic subunit (PhK-T) plays a critical role in regulation of glycogen mobilization in developing lung">
<meta name="citation_author" content="Liu, Li">
<meta name="citation_author" content="Rannels, Stephen R.">
<meta name="citation_author" content="Falconieri, Mary">
<meta name="citation_author" content="Phillips, Karen S.">
<meta name="citation_author" content="Wolpert, Ellen B.">
<meta name="citation_author" content="Weaver, Timothy E.">
<meta name="citation_publication_date" content="1996/05/17">
<meta name="citation_journal_title" content="Journal of Biological Chemistry">
<meta name="citation_volume" content="271">
<meta name="citation_issue" content="20">
<meta name="citation_firstpage" content="11761">
<meta name="citation_lastpage" content="11766">
<meta name="citation_pdf_url" content="http://www.example.com/content/271/20/11761.full.pdf">
</head>
```
**4. Conclusion**
By adhering to this specification, articles published on the Nvcleus Publishing Platform will have properly structured meta tags for Google Scholar to easily index and display them in its search results. This will improve the visibility and discoverability of the content for researchers and readers worldwide.https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1364[Multitenancy] Add ability to move between groups2023-08-01T05:22:53ZRyan Dix-Peek[Multitenancy] Add ability to move between groupsAmnet multi-tenancy v2https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1362[CoLab] Add 'field placeholder' to ThreadedDiscussion2023-12-06T10:42:50ZRyan Dix-Peek[CoLab] Add 'field placeholder' to ThreadedDiscussionConsidered that it may not be clear that Authors can identify that they can capture feedback in the ThreadeDisucssion reply field on the `/submit` page. The ThreadedDiscussion does not utilise the 'Field placeholder this could be used to...Considered that it may not be clear that Authors can identify that they can capture feedback in the ThreadeDisucssion reply field on the `/submit` page. The ThreadedDiscussion does not utilise the 'Field placeholder this could be used to identify/provide further instruction to the author.
The suggestion is to add the 'Field placeholder' field to the Forms>Decision>`ThreadedDiscussion` settings
![Screenshot_2023-07-27_at_15.29.56](/uploads/c65369f65553c01553036a7e05a9328a/Screenshot_2023-07-27_at_15.29.56.png)
![Screenshot_2023-07-27_at_15.29.27](/uploads/66cc10053f46dd2faa8d583393ab188a/Screenshot_2023-07-27_at_15.29.27.png)CoLab Biophysics v7https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1361[CoLab] Control panel discussion default display2023-07-27T13:23:17ZRyan Dix-Peek[CoLab] Control panel discussion default displayWhen opening the Control, the default discussion channel is the 'Author discussion' There is a risk that Editors erroneously publish sensitive information in the Author discussion channel. Edit/delete features will help revert this, but ...When opening the Control, the default discussion channel is the 'Author discussion' There is a risk that Editors erroneously publish sensitive information in the Author discussion channel. Edit/delete features will help revert this, but a strategy is required to mitigate this.
The suggestion is to initially, display the Editorial discussion channel when opening the Control panel.
![Screenshot_2023-07-27_at_15.22.44](/uploads/ec3bcf8ec77abc4c9cbeced911cbae96/Screenshot_2023-07-27_at_15.22.44.png)https://gitlab.coko.foundation/kotahi/kotahi/-/issues/1356Users can reply to ThreadedDiscussion from Review page2023-07-26T09:09:41ZRyan Dix-PeekUsers can reply to ThreadedDiscussion from Review pageAs a user participating in a Threaded Discussion, I'm able to reply from the 'Evaluation summary' on the review page. The 'Evaluation summary' section should be read-only.
![Screenshot_2023-07-25_at_13.40.49](/uploads/1773ec7a89d0580e6...As a user participating in a Threaded Discussion, I'm able to reply from the 'Evaluation summary' on the review page. The 'Evaluation summary' section should be read-only.
![Screenshot_2023-07-25_at_13.40.49](/uploads/1773ec7a89d0580e63b34ca84cf682e5/Screenshot_2023-07-25_at_13.40.49.png)