pubsweet issueshttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues2019-04-02T07:49:07Zhttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/386styleguide-demo.coko.foundation -- left hand frame does not work on Safari2019-04-02T07:49:07ZBrian Tinglestyleguide-demo.coko.foundation -- left hand frame does not work on SafariSafari Version 11.1 (13605.1.33.1.2) on OS X 10.13.4
Hi, When I try to browse http://styleguide-demo.coko.foundation on safari, when I try to scroll down on the left frame, as soon as I mouse over a link text, the left frame jumps back ...Safari Version 11.1 (13605.1.33.1.2) on OS X 10.13.4
Hi, When I try to browse http://styleguide-demo.coko.foundation on safari, when I try to scroll down on the left frame, as soon as I mouse over a link text, the left frame jumps back to the top, undoing my scroll. This makes it impossible to select the lower links (unless you filter for what you want)Documentation websitehttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/384RFC: Remove `owners` as a core concept2018-05-03T14:10:39ZJureRFC: Remove `owners` as a core conceptThe concept of Owners (e.g. the `owners` of a collection) are an app-level concern, and should be handled by app-level code.The concept of Owners (e.g. the `owners` of a collection) are an app-level concern, and should be handled by app-level code.https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/383as a system operator, I would like a deamon mode2018-04-13T19:02:22ZBrian Tingleas a system operator, I would like a deamon modeFor most servers I know / write -- when you
```
serverctl start
```
you get a deamonized process (ie `fork()`, `setsid()`, `chdir()`, Close Inherited Descriptors and Standard I/O Descriptors, reset `umask()`, set up pid file etc.
and...For most servers I know / write -- when you
```
serverctl start
```
you get a deamonized process (ie `fork()`, `setsid()`, `chdir()`, Close Inherited Descriptors and Standard I/O Descriptors, reset `umask()`, set up pid file etc.
and there will be a
```
serverctl console
```
that will work like the current `pubsweet start`.
From a systems admin / ops perspective, this is much better than `nohup`
In python, there are modules that will take care of this kind of stuff for you.
I'm not a node server expert (I have a CLI and an electron app I've hacked together and maintain for a small user base) but from the research I've done, it looks like maybe `forever` is the npm module that is most well maintained with a compatible license. (`pm2` looks pretty awesome, but its AGPL)https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/382Find and remove links to deprecated repositories2018-04-17T09:37:35ZJureFind and remove links to deprecated repositoriesJureJurehttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/381Update package READMEs if they point to old repositories2019-02-14T23:11:05ZJureUpdate package READMEs if they point to old repositoriesE.g. https://gitlab.coko.foundation/pubsweet/pubsweet/tree/master/packages/server points to the old repo, and has old CI/coveraga information.E.g. https://gitlab.coko.foundation/pubsweet/pubsweet/tree/master/packages/server points to the old repo, and has old CI/coveraga information.https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/379FileUploadList isn't populated by redux-form2019-02-09T03:47:22ZAanand PrasadFileUploadList isn't populated by redux-formIn https://gitlab.coko.foundation/pubsweet/pubsweet/commit/8e76691b30915fd99f3f903c8069ffe9725949e3, the `@pubsweet/ui` components concerned with file upload were reorganised. As part of this reorg, `Files` (renamed to `FileUploadList`) ...In https://gitlab.coko.foundation/pubsweet/pubsweet/commit/8e76691b30915fd99f3f903c8069ffe9725949e3, the `@pubsweet/ui` components concerned with file upload were reorganised. As part of this reorg, `Files` (renamed to `FileUploadList`) stopped expecting a `value` prop and started expecting a `files` prop instead:
```js
class Files extends React.Component {
constructor(props) {
super(props)
this.state = {
values: props.value || [],
uploads: [],
}
}
//...
}
```
```js
class FileUploadList extends React.Component {
constructor(props) {
super(props)
this.state = {
files: props.files || [],
uploads: [],
}
}
//...
}
```
This causes a problem in `xpub-submit`'s `SubmitPage` component, which uses `redux-form` to populate form inputs. `redux-form` (at least by default) populates input components by setting their `value` prop. The result is that the list of supplementary files in the submission form is always empty.
If you upload a file, there's a brief flicker of an entry in the list, presumably after the `FileUploadList` component calls `setState` on itself, but it disappears, presumably because the component's been re-rendered/replaced.
I don't know if the convention of using `value` to populate a form input component is a strong one, but it seems to me like hewing to it (i.e. renaming the `files` prop back to `value`) is the correct solution here. Thoughts?https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/378PasswordReset-server should use SendMail-server2019-12-16T12:39:57ZJurePasswordReset-server should use SendMail-serverhttps://gitlab.coko.foundation/pubsweet/pubsweet/tree/master/packages/components/SendEmail-serverhttps://gitlab.coko.foundation/pubsweet/pubsweet/tree/master/packages/components/SendEmail-serverhttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/377Improve Signup component error messages2018-12-17T23:22:39ZJureImprove Signup component error messagesCurrently, e.g. if a user already exists, the error will be something like 'Conflict'
![image](/uploads/487548d6832eb2ed5a17847b8719ae86/image.png)
If the validation fails, it would be `Bad Request`.
We can make those error messages n...Currently, e.g. if a user already exists, the error will be something like 'Conflict'
![image](/uploads/487548d6832eb2ed5a17847b8719ae86/image.png)
If the validation fails, it would be `Bad Request`.
We can make those error messages nicer, to say things like 'A user with this username already exists', maybe at this point: https://gitlab.coko.foundation/pubsweet/pubsweet/blob/master/packages/components/Signup/Signup.jsx#L24
Inspired by #104https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/376RFC: Improve Team model2019-02-14T05:58:59ZJureRFC: Improve Team modelAs the case in xpub's reviewers has shown, there's a need to store more information about members of teams. In the case of reviewers, this is e.g. what their status is, have they received an email, etc.
This is metadata that's important...As the case in xpub's reviewers has shown, there's a need to store more information about members of teams. In the case of reviewers, this is e.g. what their status is, have they received an email, etc.
This is metadata that's important to store sensibly, currently xpub stores this in `reviewers` properties on collections and fragments, but semantically, reviewers are best represented as members of a team. Having them as team members also reduces the friction when writing authsome/authorization modes.
My suggestion is that core's Team model gets a new property `membersMetadata`, an object that contains team-related information about specific members. The Team model should also manage this property, e.g. if a user is no longer a member of a team, remove the associated `memberMetadata`, etc.
```
Team {
id
teamType: 'reviewers'
object: { type: 'fragment', id: 'someId' }
members: [ids of reviewers]
membersMetadata: {
reviewer1Id: { status: 'invited', email: 'sent' }
reviewer2Id: { status: 'declined' }
reviewer3Id: { status: 'accepted' }
}
}
```
Storing this in teams also means that we can have some reusable (cross-app) helpers in our authsome modes, for example `isActiveReviewer`, where this goes and checks if there is a team, around this object, that the user is a member of, where `team.membersMetadata[reviewerId].status === acccepted`.https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/375Lerna --no-verify and prettier mismatch2018-04-09T11:41:28ZJureLerna --no-verify and prettier mismatchDescribed here: https://github.com/lerna/lerna/pull/1219#issuecomment-378909355
Two solutions:
1. We make prettier ignore package.jsons, but that makes their formatting "uncontrolled"
2. We submit a lerna PR that makes this `--no-verify...Described here: https://github.com/lerna/lerna/pull/1219#issuecomment-378909355
Two solutions:
1. We make prettier ignore package.jsons, but that makes their formatting "uncontrolled"
2. We submit a lerna PR that makes this `--no-verify` bit optionalhttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/374Get a permanent deployment of styleguide up on pubsweet.coko.foundation/style...2019-04-02T07:51:22ZJureGet a permanent deployment of styleguide up on pubsweet.coko.foundation/styleguideDocumentation websitehttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/373Add tests for INK server component2019-02-14T05:50:22ZJureAdd tests for INK server componenthttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/372Define coko theme2018-05-04T12:05:35ZYannis BarlasDefine coko themeNow that we have a coko theme, we need to define all its variables and component-specific styles.Now that we have a coko theme, we need to define all its variables and component-specific styles.julientaqjulien@coko.foundationjulientaqjulien@coko.foundationhttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/371RFC: lightweight service container2020-01-21T15:31:57ZTamlyn RhodesRFC: lightweight service container## Problem
There are a number of cross-cutting concerns which cannot easily be componentised using the current component system since they need to be used by other components without being referred to by name. So far we have:
- `email`...## Problem
There are a number of cross-cutting concerns which cannot easily be componentised using the current component system since they need to be used by other components without being referred to by name. So far we have:
- `email` - provides a way for components to send email without caring about the underlying delivery mechanism
- `auth` - components need to check authorisation without knowing which authsome mode is being used
- `logger` - components need to log stuff without knowing where it is going
- `file storage` - components need to write and read file data without knowing where it is stored
## Current solutions
Currently we are using a mixture of patterns to achieve this:
- `email` and `auth` - implement the service in a module and put a reference to the module in the app config. This leads to odd-looking code like `const mode = require(config.get('authsome.mode'))`. It's also not clear in the config which values are actually module references.
- `logger` - store the actual service in the config but create a dedicated package for it and expose a method which allows application code to replace this value at runtime and have this change affect all consumers of the service. The first part (non-serialisable objects in config) leads to problems with node-config and the second part (dedicated package per service) is a lot of repeated code.
- `file storage` - doesn't exist yet
## Proposed solution
Create a small wrapper to standardise the way we do this.
Add a section in the config:
```json
"services": {
"server": {
"email": "@pubsweet/aws-ses-mailer",
"auth": "./src/auth/mode.js",
"logger": "winston",
...
},
"client": {
"auth": "./src/auth/mode.js"
}
},
```
Then consume a service like:
```js
const services = require('pubsweet-server/src/services')
const mailer = services('email')
```
or
```js
const services = require('pubsweet-client/src/services')
const authsome = services('auth')
```https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/370RFC: JATS as a source of names for things and more2018-05-25T08:49:21ZJureRFC: JATS as a source of names for things and moreThis isssue a 'move' from an email discussion with @MelissaHarrison and @bluerezz from eLife about the ways we could use JATS.
Here's how it's gone down so far (hope this is usefully formatted):
# from Jure #
> So, help me think throug...This isssue a 'move' from an email discussion with @MelissaHarrison and @bluerezz from eLife about the ways we could use JATS.
Here's how it's gone down so far (hope this is usefully formatted):
# from Jure #
> So, help me think through this. I think there’s two things at play in terms of the relationship between xpub and JATS: 1. storing article content and all required metadata in JATS, 2. using JATS as a source of vocabulary for things.
>I think what we agreed on the meeting was more of number 2 than number 1. For example, my concern and the reason I raised it as a discussion, was that across different xpub apps we shouldn’t have things that are semantically the same, named differently: a Paper, an Article, a ResearchPaper, a Manuscript etc. Naming things is hard and we have the luxury of a vocabulary of things, namely JATS, that has a high level of adoption in this space. So why not use it? In the example above, just call those things Article. That was my question at the meeting and I think the parties involved agreed that it makes sense.
> As for number 1, representing data and metadata in actual JATS is a different matter. I think some organizations that we work with might be less set on using JATS throughout their workflow, as long as the export to it at any point is easy. In any case, I think number 1 is a different and broader discussion, but definitely one worth having.
> What do you think?
# from Melissa #
> I think there are 3 things:
1. storing article content and all required metadata in JATS
2. using JATS as a source of vocabulary for things
3. How do we define the data model for actions, processes, and notes that are not currently catered for in JATS.
> So, I reveiwed eLife initial submission screen wireframes with Nick and there is a significant detail of information there that needs to be recorded (and potentially sent onwards) that does not fit the current JATS model.
I've been talking to others in the publishing space who have long and good experience on modelling data about papers as well as modelling the "content" that is published. All of this is integral to publishing process but not necessarily to the published information.
> I want to forward think so that any of the information we collect that we think may be published in the future is modelled somehow in JATS.
> The issue of annotations is one of these - as peer review comments/documentation is becoming more and more open, and publishable, I think we should prepare for this future by modelling commenting into JATS, and we have interest from great XML minds to be involved in this, which we should capitalise on. But happy if we do that as an eLife rather than Coko thing.
# from Paul #
> Seems sensible to me, and I agree there are 3 steps to this, each of which shouldn't delay the other. At the meeting last month, I was thinking the xPub community needed an Ubiquitous Language (as Eric Evans describes it) that would extend beyond the developer/user relationship - the naming in JATS is a great starting point for that. We should then extend our ubiquitous language for areas not covered by JATS and that can form the basis of updates to JATS in the future. Presumably, that's when the minutiae of the detail will be debated.
> It feels like we need something more concrete before getting too many others involved, so the approach of setting a community standard for these new bits first, then having that emerge as a de facto standard seems sensible. You're right about the slow movement though, we shouldn't wait too long. The priority should be that eLife, Hindawi, Collabra, Wormbase and EuropePMC all call a manuscript a manuscript when it's stored, and know the synonyms used for display too. I've developed ubiquitous languages before (usually as structured wiki pages) and it really helps.
> I'll bring this up at the next YLD/eLife workshop tomorrow as there will be talk about data models.
With this preamble, I open the floor for discussion!https://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/369What do to with components that are optional for an app's functionality2020-01-21T15:19:56ZJureWhat do to with components that are optional for an app's functionalitySpecifically, as discussed in !148, it's expected that Editoria in certain instances will not use INK, but in certain it will require it. There are a few suggestions on how to handle this:
1. relying on components.json
2. adding an inkEn...Specifically, as discussed in !148, it's expected that Editoria in certain instances will not use INK, but in certain it will require it. There are a few suggestions on how to handle this:
1. relying on components.json
2. adding an inkEnabled toggle in the config somewhere
3. your suggestion herehttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/368test issue 22018-03-28T18:23:50ZSam Galsontest issue 2bodybodyhttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/367Revewer should receive an invitation email2018-04-24T13:21:00ZGiannis Kopanasjkopanas@gmail.comRevewer should receive an invitation emailthis is related with that one https://gitlab.coko.foundation/xpub/xpub/issues/160this is related with that one https://gitlab.coko.foundation/xpub/xpub/issues/160Giannis Kopanasjkopanas@gmail.comGiannis Kopanasjkopanas@gmail.comhttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/366test issue2018-04-09T10:08:15ZSam Galsontest issuetest bodytest bodyhttps://gitlab.coko.foundation/pubsweet/pubsweet/-/issues/365Visual regression testing for styleguide2019-02-14T23:31:10ZTamlyn RhodesVisual regression testing for styleguideThis is particularly useful to run locally when refactoring components to check that you haven't accidentally broken anything. It may not make sense to integrate into CI until the components have stabilised a bit.
I got quite far with [...This is particularly useful to run locally when refactoring components to check that you haven't accidentally broken anything. It may not make sense to integrate into CI until the components have stabilised a bit.
I got quite far with [React Styleguide Visual](https://github.com/unindented/react-styleguidist-visual) but there are a [few](https://github.com/unindented/react-styleguidist-visual/issues/13) [issues](https://github.com/unindented/react-styleguidist-visual/issues/14) to resolve.Documentation website