xpub-collabra issueshttps://gitlab.coko.foundation/xpub/xpub/-/issues2018-07-01T10:17:43Zhttps://gitlab.coko.foundation/xpub/xpub/-/issues/202Editor makes decision e2e test - revise manuscript2018-07-01T10:17:43ZAna EllisEditor makes decision e2e test - revise manuscriptAs an editor:
There should be one accepted manuscript in the "My Manuscripts" section.
1. Under "My Manuscripts" there should be one manuscript.
2. Click on the link that takes you to the Control Panel.
3. Fill in the Decision text a...As an editor:
There should be one accepted manuscript in the "My Manuscripts" section.
1. Under "My Manuscripts" there should be one manuscript.
2. Click on the link that takes you to the Control Panel.
3. Fill in the Decision text area.
4. Choose "Revise" as a decision.
5. Submit the review form.
6. Go to the dashboard.
7. Verify that the manuscript status in the "My Submissions" section is "Back with author for review".
8. The manuscript should have a link that says "Completed:rejected".
9. Click on this link.
10. Verify that you are taken to the Decision form again.
11. Verify that the decision form is now read-only.Ana EllisAna Ellishttps://gitlab.coko.foundation/xpub/xpub/-/issues/201Editor makes accept or reject desicion e2e test2018-06-25T11:26:18ZAna EllisEditor makes accept or reject desicion e2e testAs an editor:
Accept:
There should be one accepted manuscript in the "My Manuscripts" section.
1. Under "My Manuscripts" there should be one manuscript.
2. Click on the link that takes you to the Control Panel.
3. Fill in the Decisi...As an editor:
Accept:
There should be one accepted manuscript in the "My Manuscripts" section.
1. Under "My Manuscripts" there should be one manuscript.
2. Click on the link that takes you to the Control Panel.
3. Fill in the Decision text area.
5. Choose "Accept" as a decision.
6. Submit the review form.
7. Go to the dashboard.
8. The manuscript should have a link that says "Completed:accepted".
9. Click on this link.
10. Verify that you are taken to the Decision form again.
11. Verify that the review form is now read-only.
Reject:
There should be one accepted manuscript in the "My Manuscripts" section.
1. Under "My Manuscripts" there should be one manuscript.
2. Click on the link that takes you to the Control Panel.
3. Fill in the Decision text area.
5. Choose "Reject" as a decision.
6. Submit the review form.
7. Go to the dashboard.
8. The manuscript should have a link that says "Completed:rejected".
9. Click on this link.
10. Verify that you are taken to the Decision form again.
11. Verify that the review form is now read-only.
Ana EllisAna Ellishttps://gitlab.coko.foundation/xpub/xpub/-/issues/200Reviewer completes review - review accepted or rejected2018-06-26T14:14:00ZAna EllisReviewer completes review - review accepted or rejected_As a reviewer:_
There should be one accepted review in the "My Reviews" section.
1. Under "My Reviews" there should be one manuscript.
2. Click on the link that takes you to the review page.
3. Fill in the review text area.
4. Fill..._As a reviewer:_
There should be one accepted review in the "My Reviews" section.
1. Under "My Reviews" there should be one manuscript.
2. Click on the link that takes you to the review page.
3. Fill in the review text area.
4. Fill in the confidential text area.
5. Choose "Accept" as a recommendation to the editor.
6. Submit the review form.
7. Go to the dashboard.
8. The manuscript should have a link that says "Completed".
9. Click on this link.
10. Verify that you are taken to the review form again.
11. Verify that the review form is now read-only.
There should be one accepted review in the "My Reviews" section.
1. Under "My Reviews" there should be one manuscript.
2. Click on the link that takes you to the review page.
3. Fill in the review text area.
4. Fill in the confidential text area.
5. Choose "Reject" as a recommendation to the editor.
6. Submit the review form.
7. Go to the dashboard.
8. The manuscript should have a link that says "Completed".
9. Click on this link.
10. Verify that you are taken to the review form again.
11. Verify that the review form is now read-only.Ana EllisAna Ellishttps://gitlab.coko.foundation/xpub/xpub/-/issues/177Submission info Page - Issue with Fields in Prosemirror Editor2018-04-20T15:33:48ZGiannis Kopanasjkopanas@gmail.comSubmission info Page - Issue with Fields in Prosemirror EditorThe issue here is that at the "submission info" Page and specifically in "Title", "Abstract", "Funding body acknowledgement", and "Special instruction" field.
We let the User type the desired text in an editor and then during the proces...The issue here is that at the "submission info" Page and specifically in "Title", "Abstract", "Funding body acknowledgement", and "Special instruction" field.
We let the User type the desired text in an editor and then during the process of saving and updating with striping the html tags. That means that the authors' intent
might be lost. From the other hand if we let the author free to make any formation desires, then we will have problem to the pages that this content is shown.
The solution is either change the input form to plain text, or to display the HTML correctly (somehow) in the page.https://gitlab.coko.foundation/xpub/xpub/-/issues/167Set default secret in development2018-04-26T16:29:59ZTamlyn RhodesSet default secret in developmentCurrently the `secret` is generated on `pubsweet new` and saved into `config/local.json`. But this means if you clone the repo instead, the app won't start until you provide a secret. The secret is used to encode JWTs so only needs to be...Currently the `secret` is generated on `pubsweet new` and saved into `config/local.json`. But this means if you clone the repo instead, the app won't start until you provide a secret. The secret is used to encode JWTs so only needs to be secret in production.
So instead of generating a random secret, we should provide a default secret in `config/development.js` and `config/test.js` and instructions to generate a proper secret when moving to production.
Editoria and Starter will also need updating.Giannis Kopanasjkopanas@gmail.comGiannis Kopanasjkopanas@gmail.comhttps://gitlab.coko.foundation/xpub/xpub/-/issues/76Make more use of selectors2017-12-20T18:15:08ZTamlyn RhodesMake more use of selectors## Motivation
- Using selector functions to access the state helps with code reuse
- Well designed selectors can be composed in ways that make refactoring much easier
- Selectors are pure and easy to test
- Container components are hard ...## Motivation
- Using selector functions to access the state helps with code reuse
- Well designed selectors can be composed in ways that make refactoring much easier
- Selectors are pure and easy to test
- Container components are hard to test and benefit from being kept small and logic free
## Approach
- Create selectors for each atom of state access: `selectFragments`, `selectVersions`, `selectLatestVersion`...
- There is already an `xpub-selectors` package
- I fear this will not scale when it comes to having multiple xpub implementations
- However organisation of selectors is a particularly hard (unsolved?) problem and I don't have a better suggestion
- Update all instances of `mapStateToProps` to use selectors instead of directly accessing the state
- Use [Reselect](https://github.com/reactjs/reselect) which is a popular library for composing selectors which also brings some performance benefitsXpubhttps://gitlab.coko.foundation/xpub/xpub/-/issues/234RFC: Simple Form Builder2019-01-15T12:50:59ZGiannis Kopanasjkopanas@gmail.comRFC: Simple Form BuilderHaving the knowledge of the previous version of form Builder, the need of a simpler version is imperative.As a starting point we need to focus on extensibility rather than features that will be time consuming to maintain. So to start wit...Having the knowledge of the previous version of form Builder, the need of a simpler version is imperative.As a starting point we need to focus on extensibility rather than features that will be time consuming to maintain. So to start with, our current goal is to create a component which creates a form with three basic elements, Label, Label + Text , Label + Radio Box. This implementation is only focused on the frontEnd this has nothing to do with the saving and retrieving the form from the Database. The main parts of a Form that we should consider first are :
1. "UI Library" which represent the actual Elements of The Form
The actual elements that will be shown in the form. We should have a tank of Elements to use for the Form Builder.
For now we will have only 3 kinds of UI Elements Label, Label with TextField, Label with RadioBox. A good option for that
purpose could be the pubsweet-ui Package.
2. Library that will be used for the form Builder ( Formik , redux-form etc. )
This is not important for now i just wanted to have the whole idea of the basic Steps we need to build a Form.
3. Settings of each UI Element. (we definitely not care, which those settings should be for now)
An ui Element may has many properties in order to fulfill the requirements of a form. An example could be Validation / Placeholder / Visibility etc. For now the only think that we need is to have a way to have independent and different settings per UI Elements.
An example in our Case is :
For the Label UI Element we need some settings in order to be shown correctly to the end user and that setting as a start is
an Editor (text area) where the administrator could save the actual Value of the Label to be shown. Even those settings at that point are Hard-coded.
4. Layout The actual Component that will host the UI Elements.
Mechanism based on "Strategy pattern" that will load different Component Views. At the current Point will be only a default Layout or a custom layout that the developer will create. Everything will be hard-coded it but the mechanism should exist to serve the extensibility requirement
5. Minimal configuration from developer's perspective to show the Form.
Just a starting point for a developer to show the Form in the Page Something like :
new SimpleForm({ layout: 'myForm' }) if no layout is specified a default predefined layout should be shown.
The idea is to create Each of those Parts and be based on patterns having in mind the extensibility.https://gitlab.coko.foundation/xpub/xpub/-/issues/233New Data model migration Backend Models2018-11-22T16:37:32ZGiannis Kopanasjkopanas@gmail.comNew Data model migration Backend ModelsCreating new Models:
* [x] Journal
* [x] Manuscript
* [x] Review
* [x] Comments
* [x] Files
* [x] Notes
* [x] Teams (Find a solution for slight migration to new Data model)
* [ ] User (extend typedefs for signup user)
* [ ] For...Creating new Models:
* [x] Journal
* [x] Manuscript
* [x] Review
* [x] Comments
* [x] Files
* [x] Notes
* [x] Teams (Find a solution for slight migration to new Data model)
* [ ] User (extend typedefs for signup user)
* [ ] Formbuilder Backend (is not necessary)
* [ ] Use new Jure's Authsome Implementation
* [ ] Tests for Each modelhttps://gitlab.coko.foundation/xpub/xpub/-/issues/231Mock graphql Server2018-09-10T14:24:37ZGiannis Kopanasjkopanas@gmail.comMock graphql ServerMocking the graphql server so the development in the xpub frontend components can move on independent
from the back end serverMocking the graphql server so the development in the xpub frontend components can move on independent
from the back end serverGiannis Kopanasjkopanas@gmail.comGiannis Kopanasjkopanas@gmail.comhttps://gitlab.coko.foundation/xpub/xpub/-/issues/229PDF upload at submission creates issue for subsequent submissions2018-08-14T00:12:15ZAlison McGonagle-O’ConnellPDF upload at submission creates issue for subsequent submissionson xpub-testing.coko.foundation, I encountered the following behavior:
1) Upload PDF file at submission.
2) Title is extracted, within submission form that pops up immediately.
3) click to view the manuscript, the preview is unavailable...on xpub-testing.coko.foundation, I encountered the following behavior:
1) Upload PDF file at submission.
2) Title is extracted, within submission form that pops up immediately.
3) click to view the manuscript, the preview is unavailable.
4) submit as usual once all author data/ questions/ other requirements are met.
5) try to start a new submission with a .docx upload
6) toggle from the submission form view to the manuscript preview after upload
7) toggle back to the submission form
8) submission title is overwritten with the title from the first PDF submission (though these submissions are in no way related)
9) moving from submission form back to the manuscript preview, at this point, yields the unavailable preview (though the preview had been available initially.
Expected behavior:
I expected that, because the interface said it could handle PDF, latex, EPUB, that I could test these formats. Even if the preview had not been available, the errors with subsequent submissions were not what was expected and seem like they could be representative of a bug.https://gitlab.coko.foundation/xpub/xpub/-/issues/225Accepted manuscript status on dashboard2018-07-23T13:01:58ZAlison McGonagle-O’ConnellAccepted manuscript status on dashboardOn the author's dashboard, submissions that are rejected currently pull in as "Rejected"; manuscripts that receive a revise decision also pull in with the appropriate revision status. However, when a manuscript is accepted, on this autho...On the author's dashboard, submissions that are rejected currently pull in as "Rejected"; manuscripts that receive a revise decision also pull in with the appropriate revision status. However, when a manuscript is accepted, on this author facing dashboard, the manuscript shows up as "rejected" when it should be "Accepted."https://gitlab.coko.foundation/xpub/xpub/-/issues/224Reviewer management metrics need adjustment2018-08-08T14:36:49ZAlison McGonagle-O’ConnellReviewer management metrics need adjustmentOn the Editor dashboard, where the number of reviewers invited, etc. show up beneath the manuscript title, "Invited" should be the total number of reviewers invited ever, regardless of response/ reviewer activity. For example, if 4 have ...On the Editor dashboard, where the number of reviewers invited, etc. show up beneath the manuscript title, "Invited" should be the total number of reviewers invited ever, regardless of response/ reviewer activity. For example, if 4 have been invited, and two 'reject,' (or decline assignment) the total should be: 4 invited, 2 rejected. Not 2 invited 2 rejected.https://gitlab.coko.foundation/xpub/xpub/-/issues/223Design for long text boxes2018-07-17T03:06:55ZAlex ThegDesign for long text boxesCurrently, even longer text boxes are not very long. Some text inputs are expected to be quite long (for example, reviews). We will need to consider the best interface for these longer fields.Currently, even longer text boxes are not very long. Some text inputs are expected to be quite long (for example, reviews). We will need to consider the best interface for these longer fields.https://gitlab.coko.foundation/xpub/xpub/-/issues/220Limit SE and HE editor assignment dropdown options to people with those permi...2018-07-17T02:31:22ZAlex ThegLimit SE and HE editor assignment dropdown options to people with those permissionsSenior Editors and Handling Editors are discrete lists, and not everyone should be able to be assigned as an SE or HE.
To prevent users being assigned an incorrect role on a manuscript, the Senior Editor assignment drop-down should show...Senior Editors and Handling Editors are discrete lists, and not everyone should be able to be assigned as an SE or HE.
To prevent users being assigned an incorrect role on a manuscript, the Senior Editor assignment drop-down should show only the subset of users who have Senior Editor permissions, and the Handling Editor assignment drop-down should only show the subset of users who can act as Handling Editors.https://gitlab.coko.foundation/xpub/xpub/-/issues/218Add new notification emails2018-07-16T23:49:21ZAlex ThegAdd new notification emailsThe following emails should be added as xPub notifications that are triggered by the following actions:
* When Admin assigns a Senior Editor
* When Senior Editor assigns a Handling Editor
The text of these emails and the exact functiona...The following emails should be added as xPub notifications that are triggered by the following actions:
* When Admin assigns a Senior Editor
* When Senior Editor assigns a Handling Editor
The text of these emails and the exact functionality needs designing.https://gitlab.coko.foundation/xpub/xpub/-/issues/217Ability to customize notification emails2018-07-16T23:32:54ZAlex ThegAbility to customize notification emailsFeature request: the ability to customize the notification emails sent to authors, editors, and reviewers before they're sent.Feature request: the ability to customize the notification emails sent to authors, editors, and reviewers before they're sent.https://gitlab.coko.foundation/xpub/xpub/-/issues/216Design: summary of reviewer invitation and review status2018-07-16T23:31:19ZAlex ThegDesign: summary of reviewer invitation and review statusDan writes:
> Count of invited/accepted/rejected/completed should work more logically. E.g. current status for blame game paper should be 3 invited 1 accepted 0 declined 1 complete. For the blame game paper, if all review invitations ar...Dan writes:
> Count of invited/accepted/rejected/completed should work more logically. E.g. current status for blame game paper should be 3 invited 1 accepted 0 declined 1 complete. For the blame game paper, if all review invitations are accepted and completed it would say 3 invited 3 accepted 0 rejected 3 Completed. Can this reviewer summary also feature on Control Panel near “Select Reviewer” button?
This is worth discussing on a call to flesh it out further.https://gitlab.coko.foundation/xpub/xpub/-/issues/215Lock Submission Info once manuscript is submitted2018-07-13T21:45:11ZAlex ThegLock Submission Info once manuscript is submittedWhen an author submits a manuscript, the author can still change the data associated with his or her paper:
* Create a new submission as an author
* Submit it
* From the dashboard, click on the "Summary Info"
The submission information ...When an author submits a manuscript, the author can still change the data associated with his or her paper:
* Create a new submission as an author
* Submit it
* From the dashboard, click on the "Summary Info"
The submission information is still editable as the author.
Instead, the author's submission information should be locked so the author can't change it once the manuscript has been submitted.https://gitlab.coko.foundation/xpub/xpub/-/issues/213Update permissions for who can assign/change SE and HE2018-07-13T21:22:31ZAlex ThegUpdate permissions for who can assign/change SE and HEThe admin user should be able to set and change the SE and HE assigned to a manuscript, but it appears that anyone can (even though changing SE or HE doesn't actually work - see #212).
Currently, anyone with access to the ms control pan...The admin user should be able to set and change the SE and HE assigned to a manuscript, but it appears that anyone can (even though changing SE or HE doesn't actually work - see #212).
Currently, anyone with access to the ms control panel can use the dropdown to select a different HE and SE. The permissions should be as follows:
* Admin should be able to assign SE and HE as currently implemented
* SE should only be able to assign HE
* HE should _not_ be able to change assigned SEs or HEs (HE should only be able to invite reviewers)
* Reviewers shouldn't be able to set or change SE or HEhttps://gitlab.coko.foundation/xpub/xpub/-/issues/211Update metadata visible to different roles2018-07-17T03:41:08ZAlex ThegUpdate metadata visible to different rolesIn the Control Panel and Review Screens, some of the visible information needs to be obscured from certain roles:
* Only admin should see the suggested and opposed editors
* Only admin, SE and HE should see the suggested/opposed reviewer...In the Control Panel and Review Screens, some of the visible information needs to be obscured from certain roles:
* Only admin should see the suggested and opposed editors
* Only admin, SE and HE should see the suggested/opposed reviewers, and the "Special instructions".
* Reviewers should not see anything past the yes/no metadata questions (hide from them suggested/opposed editors, suggested/opposed reviewers, and "Special instructions"