diff --git a/.fly/kotahi-server-test.toml b/.fly/kotahi-server-test.toml
index d7d389319..eabbcf460 100644
--- a/.fly/kotahi-server-test.toml
+++ b/.fly/kotahi-server-test.toml
@@ -11,7 +11,7 @@ app = "bash -c 'sh /custom/start.sh && exec yarn coko-server start'"
auto_start_machines = true
auto_stop_machines = true
force_https = true
-internal_port = 8_080
+internal_port = 8080
min_machines_running = 0
processes = ["app"]
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
deleted file mode 100644
index 6198cebb0..000000000
--- a/.gitlab-ci.yml
+++ /dev/null
@@ -1,201 +0,0 @@
-# include:
-# - project: 'cokoapps/ci'
-# ref: main
-# file: 'ci-templates.yml'
-
-variables:
- IMAGE_NAME_DEVELOPMENT: kotahi/kotahi/root-development
- CLIENT_PREPRODUCTION: $CI_REGISTRY/kotahi/kotahi/client-preproduction:$CI_COMMIT_REF_NAME
- SERVER_PREPRODUCTION: $CI_REGISTRY/kotahi/kotahi/server-preproduction:$CI_COMMIT_REF_NAME
- CLIENT_PRODUCTION: cokoapps/kotahi-client
- SERVER_PRODUCTION: cokoapps/kotahi-server
- DEV_DOCS: $CI_REGISTRY/kotahi/kotahi/devdocs:$CI_COMMIT_REF_NAME
- DEPLOY_COMPOSE_FILE: docker-compose.ci.yml
-
-stages:
- - Build development
- - Lint & Unit test
- - Build production
- - Deploy test
- - End to end testing
- - Tear down test
- - Deploy staging
- - Release
- - Publish
- - Deploy production
-
-build development:
- stage: Build development
- interruptible: true
- image: docker:27-dind
- services:
- - docker:27-dind
- before_script:
- - echo "$CI_REGISTRY_PASSWORD" | docker login "$CI_REGISTRY" -u "$CI_REGISTRY_USER" --password-stdin
- script:
- - docker build
- --tag $CI_REGISTRY/$IMAGE_NAME_DEVELOPMENT:$CI_COMMIT_REF_NAME.$CI_COMMIT_SHA
- -f Dockerfile .
- - docker push $CI_REGISTRY/$IMAGE_NAME_DEVELOPMENT:$CI_COMMIT_REF_NAME.$CI_COMMIT_SHA
-
-lint:
- stage: Lint & Unit test
- interruptible: true
- image: $CI_REGISTRY/$IMAGE_NAME_DEVELOPMENT:$CI_COMMIT_REF_NAME.$CI_COMMIT_SHA
- script:
- - cd /home/node/app
- - yarn coko-lint run
-
-build preproduction client:
- stage: Build production
- interruptible: true
- image: docker:27
- services:
- - docker:27-dind
- only:
- - staging
- - main
- before_script:
- - echo "$CI_REGISTRY_PASSWORD" | docker login "$CI_REGISTRY" -u "$CI_REGISTRY_USER" --password-stdin
- script:
- - cd packages/client
- - docker build
- --tag $CLIENT_PREPRODUCTION.$CI_COMMIT_SHA
- --tag $CLIENT_PREPRODUCTION.latest
- -f Dockerfile-production .
- - docker push $CLIENT_PREPRODUCTION.$CI_COMMIT_SHA
- - docker push $CLIENT_PREPRODUCTION.latest
-
-build preproduction server:
- stage: Build production
- interruptible: true
- image: docker:27
- services:
- - docker:27-dind
- only:
- - staging
- - main
- before_script:
- - echo "$CI_REGISTRY_PASSWORD" | docker login "$CI_REGISTRY" -u "$CI_REGISTRY_USER" --password-stdin
- script:
- - cd packages/server
- - docker build
- --tag $SERVER_PREPRODUCTION.$CI_COMMIT_SHA
- --tag $SERVER_PREPRODUCTION.latest
- -f Dockerfile-production .
- - docker push $SERVER_PREPRODUCTION.$CI_COMMIT_SHA
- - docker push $SERVER_PREPRODUCTION.latest
-
-deploy fly staging:
- stage: Deploy staging
- interruptible: false
- image: cokoapps/fly
- only:
- - staging
- script:
- - FLY_API_TOKEN=$FLY_SERVER_TEST_TOKEN flyctl deploy --config .fly/kotahi-server-test.toml --image $SERVER_PREPRODUCTION.$CI_COMMIT_SHA
- - FLY_API_TOKEN=$FLY_CLIENT_TEST_TOKEN flyctl deploy --config .fly/kotahi-client-test.toml --image $CLIENT_PREPRODUCTION.$CI_COMMIT_SHA
-
-deploy fly main:
- stage: Deploy staging
- interruptible: false
- image: cokoapps/fly
- only:
- - main
- script:
- - FLY_API_TOKEN=$FLY_SERVER_MAIN_TOKEN flyctl deploy --config .fly/kotahi-server-main.toml --image $SERVER_PREPRODUCTION.$CI_COMMIT_SHA
- - FLY_API_TOKEN=$FLY_CLIENT_MAIN_TOKEN flyctl deploy --config .fly/kotahi-client-main.toml --image $CLIENT_PREPRODUCTION.$CI_COMMIT_SHA
-
-release:
- stage: Release
- interruptible: false
- image: node:20
- when: manual
- only:
- - main
- before_script:
- - git remote set-url --push origin "https://gitlab-ci-token:$CI_RELEASE_TOKEN@gitlab.coko.foundation/kotahi/kotahi.git"
- - git config user.email "$CI_RELEASE_BOT_EMAIL"
- - git config user.name "kotahi release bot"
- script:
- - node scripts/updatePackageJson.js
- - VERSION=$(node -e "const packageJson = require('./package.json'); console.log(packageJson.version);")
- - echo VERSION set to $VERSION
- - git add -A
- - git commit -m "release version $VERSION [skip ci]"
- - git show-ref --tags "$VERSION" > /dev/null 2>&1 && git tag -d "$VERSION" || echo "Tag '$VERSION' does not exist."
- - git tag $VERSION
- - git push origin HEAD:$CI_COMMIT_REF_NAME --verbose
- - git push origin $VERSION
- - echo RELEASE_VERSION=$VERSION >> version.env
- artifacts:
- reports:
- dotenv: version.env
-
-production client:
- stage: Publish
- interruptible: false
- image: docker:27
- services:
- - docker:27-dind
- needs:
- - release
- only:
- - main
- before_script:
- - '[ -z "$RELEASE_VERSION" ] && exit 1'
- - docker login -u $DOCKERHUB_USERNAME -p $DOCKERHUB_PASSWORD
- script:
- - git fetch origin $CI_COMMIT_REF_NAME
- - git reset --hard origin/$CI_COMMIT_REF_NAME
- - cd packages/client
- - docker build --tag $CLIENT_PRODUCTION:$RELEASE_VERSION -f Dockerfile-production .
- - docker push $CLIENT_PRODUCTION:$RELEASE_VERSION
-
-production server:
- stage: Publish
- interruptible: false
- image: docker:27
- services:
- - docker:27-dind
- needs:
- - release
- only:
- - main
- before_script:
- - '[ -z "$RELEASE_VERSION" ] && exit 1'
- - docker login -u $DOCKERHUB_USERNAME -p $DOCKERHUB_PASSWORD
- script:
- - git fetch origin $CI_COMMIT_REF_NAME
- - git reset --hard origin/$CI_COMMIT_REF_NAME
- - cd packages/server
- - docker build --tag $SERVER_PRODUCTION:$RELEASE_VERSION -f Dockerfile-production .
- - docker push $SERVER_PRODUCTION:$RELEASE_VERSION
-
-build docs:
- stage: Publish
- interruptible: false
- image: docker:27
- services:
- - docker:27-dind
- needs:
- - release
- only:
- - main
- before_script:
- - echo "$CI_REGISTRY_PASSWORD" | docker login "$CI_REGISTRY" -u "$CI_REGISTRY_USER" --password-stdin
- script:
- - cd packages/devdocs
- - docker build -f Dockerfile-production -t $DEV_DOCS.$CI_COMMIT_SHA .
- - docker push $DEV_DOCS.$CI_COMMIT_SHA
-
-deploy docs:
- stage: Deploy production
- interruptible: false
- image: cokoapps/fly
- needs:
- - build docs
- only:
- - main
- script:
- - FLY_API_TOKEN=$FLY_DEV_DOCS_TOKEN flyctl deploy --config .fly/kotahi-dev-docs.toml --image $DEV_DOCS.$CI_COMMIT_SHA
diff --git a/.gitlab/issue_templates/bug-report.md b/.gitlab/issue_templates/bug-report.md
index eda0f5447..46d81203e 100644
--- a/.gitlab/issue_templates/bug-report.md
+++ b/.gitlab/issue_templates/bug-report.md
@@ -25,4 +25,4 @@
-
+
diff --git a/CHANGES.md b/CHANGES.md
index 8cc85d0ea..63ca64b51 100644
--- a/CHANGES.md
+++ b/CHANGES.md
@@ -41,7 +41,7 @@ There's a new (optional) `S3_REGION` environment variable that let's you control
If you were previously adding the `pgcrypto` extension to your databases manually, that is no longer necessary. The extension is still necessary, but its addition will happen automatically.
-Note that there's a new major version (`2.0.0`) of the pagedjs microservice. If you switch to that, there are a couple of environment variables that you need to change. Check that repo's [changelog](https://gitlab.coko.foundation/cokoapps/pagedjs/-/blob/main/CHANGELOG.md?ref_type=heads) for details. Both versions 1 and 2 will work with kotahi.
+Note that there's a new major version (`2.0.0`) of the pagedjs microservice. If you switch to that, there are a couple of environment variables that you need to change. Check that repo's [changelog](https://github.com/Coko-Foundation/pagedjs-microservice/blob/main/CHANGELOG.md) for details. Both versions 1 and 2 will work with kotahi.
### Version 3.8.0
@@ -49,7 +49,7 @@ We've changed how translation overrides work a little. Instead of mounting files
### Version 3.7.0
-Client and server are now two separate containers in production. This means that your main url (eg. myapp.com) should now point to the client deployment, not the server. You can see the [production compose file](https://gitlab.coko.foundation/kotahi/kotahi/-/blob/3.7.0/docker-compose.production.yml?ref_type=tags) for reference. Both client and server need to have separate, publicly accessible urls.
+Client and server are now two separate containers in production. This means that your main url (eg. myapp.com) should now point to the client deployment, not the server. You can see the [production compose file](https://github.com/eLifePathways/Kotahi/blob/3.7.0/docker-compose.production.yml?ref_type=tags) for reference. Both client and server need to have separate, publicly accessible urls.
eg. If on your deployment, you are running the client on `localhost:4000` and the server on `localhost:3000`, in your nginx or equivalent configuration you will need to point eg. myapp.com to `localhost:4000` and server.myapp.com (or whatever new url you want) to `localhost:3000`.
@@ -106,7 +106,7 @@ If you have a `translationOverrides.js` file, it must be moved from `config/` fo
**Development instances only:** Any dev instances hosted on `localhost` will need to their 'Redirect URIs' changed in ORCID, to be able to log in. Alternately, if your port is 4000, you can just change the `ORCID_CLIENT_ID` in your `.env` file to the one supplied in the `.env.example` file, and no further changes should be required.
-To change 'Redirect URIs' in ORCID, follow the [instructions in the FAQ](https://gitlab.coko.foundation/kotahi/kotahi/-/blob/main/FAQ.md#how-do-i-setup-orcid-for-development), and replace any Redirect URIs mentioning "localhost" with equivalent URIs containing `127.0.0.1`.
+To change 'Redirect URIs' in ORCID, follow the [instructions in the FAQ](https://github.com/eLifePathways/Kotahi/blob/3.2.0/FAQ.md#how-do-i-setup-orcid-for-development), and replace any Redirect URIs mentioning "localhost" with equivalent URIs containing `127.0.0.1`.
#### Renaming a Group Name
@@ -133,7 +133,7 @@ Update the group name in the `.env` file.
- Replace the 'kotahi' group name with the desired group name.
- After updating the `.env` file, redeploy the application to apply the changes.
-Note: Ensure that you follow the [instructions in the FAQ](https://gitlab.coko.foundation/kotahi/kotahi/-/blob/main/FAQ.md#instance_groups-and-multitenancy) regarding `INSTANCE_GROUPS` and group specifications.
+Note: Ensure that you follow the [instructions in the FAQ](https://github.com/eLifePathways/Kotahi/blob/3.2.0/FAQ.md#instance_groups-and-multitenancy) regarding `INSTANCE_GROUPS` and group specifications.
### Version 3.1.0
@@ -188,7 +188,7 @@ Set `USE_COLAB_BIOPHYSICS_IMPORT=true` in the `.env` file. Without this, imports
Previously, all groups using the `colab` archetype performed these imports, despite them being intended for one organization only.
-In future we intend to move all imports into plugins, using the import [plugin architecture](https://docs.coko.foundation/s/f961fad5-f903-4561-9d22-b723129edf15).
+In future we intend to move all imports into plugins, using the import [plugin architecture](https://github.com/eLifePathways/Kotahi/wiki/Plugins).
### 2023-08-18: Version 2.0.0
@@ -198,9 +198,9 @@ Instances affected: **all**.
`INSTANCE_NAME` environment variable is no longer used (but may be retained in case rollback is required). Instead, the variable `INSTANCE_GROUPS` must be supplied when upgrading Kotahi to version 2.0.0 or later.
-`INSTANCE_GROUPS` is a required setting, which determines what multitenanted "groups" should run within a single instance of Kotahi. Typically, when upgrading an existing instance to 2.0.0, `INSTANCE_GROUPS` should specify a single group, though you may subsequently add further groups separated by commas to create new mulitenanted groups, each with their own data, workflow, branding and other settings (see the [FAQ](https://gitlab.coko.foundation/kotahi/kotahi/-/blob/main/FAQ.md#instance_groups-and-multitenancy) for details).
+`INSTANCE_GROUPS` is a required setting, which determines what multitenanted "groups" should run within a single instance of Kotahi. Typically, when upgrading an existing instance to 2.0.0, `INSTANCE_GROUPS` should specify a single group, though you may subsequently add further groups separated by commas to create new mulitenanted groups, each with their own data, workflow, branding and other settings (see the [FAQ](https://github.com/eLifePathways/Kotahi/blob/3.2.0/FAQ.md#instance_groups-and-multitenancy) for details).
-`INSTANCE_GROUPS` must contain one or more _group specifications_ separated by commas. Each _group specification_ consists of a _group name_ followed by a colon followed by a _group type_, e.g. `ourjournal:aperture`. The _group name_ (before the colon) may only contain lowercase `a`-`z`, `0`-`9` and the `_` character. The _group type_ (after the colon) must be either 'aperture', 'colab', 'elife' or 'ncrc'. (These [_group types_](https://docs.coko.foundation/doc/instance-archetypes-LFnzu7leM7) will be given more descriptive and generic names in the near future.)
+`INSTANCE_GROUPS` must contain one or more _group specifications_ separated by commas. Each _group specification_ consists of a _group name_ followed by a colon followed by a _group type_, e.g. `ourjournal:aperture`. The _group name_ (before the colon) may only contain lowercase `a`-`z`, `0`-`9` and the `_` character. The _group type_ (after the colon) must be either 'aperture', 'colab', 'elife' or 'ncrc'. (These _group types_ will be given more descriptive and generic names in the near future.)
Typically, to keep URLs to pages unchanged it is recommended that the _group name_ "kotahi" be used: thus, if you had `INSTANCE_NAME=aperture`, you would set `INSTANCE_GROUPS=kotahi:aperture`.
@@ -254,7 +254,7 @@ eLife only: To publish fields to Hypothesis in reverse order, so that they appea
Fields for publishing are now specified in the form-builder, rather than via `HYPOTHESIS_PUBLISH_FIELDS` in the `.env` file. If `HYPOTHESIS_PUBLISH_FIELDS` is not specified, no action is necessary. Otherwise, to retain your existing publishing options, you should:
-1. Determine what fields are selected in `HYPOTHESIS_PUBLISH_FIELDS`. Fields are separated by commas, and may consist of either a field name, or a field name and a tag separated by a colon (e.g. `fieldName:hypothesis tag`). You may also have a special `decision` or `reviews` pseudo-field specified. For full details of these old settings, [see here](https://gitlab.coko.foundation/kotahi/kotahi/-/blob/c51b72ec81e74aab915c46f0bdadc3975cc61bd9/FAQ.md#hypothesis).
+1. Determine what fields are selected in `HYPOTHESIS_PUBLISH_FIELDS`. Fields are separated by commas, and may consist of either a field name, or a field name and a tag separated by a colon (e.g. `fieldName:hypothesis tag`). You may also have a special `decision` or `reviews` pseudo-field specified. For full details of these old settings, [see here](https://github.com/eLifePathways/Kotahi/blob/c51b72ec81e74aab915c46f0bdadc3975cc61bd9/FAQ.md#hypothesis).
2. For each ordinary field that was specified in `HYPOTHESIS_PUBLISH_FIELDS`, locate that field in the submission form in the form-builder, and enable "Include when sharing or publishing".
3. If a tag was specified for that field, enter it in the "Hypothes.is tag" text box.
4. If the `decision` pseudo-field was specified, locate the field in your decision form with the internal name "comment": enable "Include when sharing or publishing", and set a hypothes.is tag if one was specified.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 9d991e7b1..73e92e031 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,33 +1,33 @@
# CONTRIBUTING
-Kotahi is a manuscript submission system, based on the discontinued [xpub-collabra](https://gitlab.coko.foundation/xpub/xpub) project.
-It is currently under development by the [Coko Foundation](https://coko.foundation/) and is being built with [PubSweet](https://gitlab.coko.foundation/pubsweet/pubsweet). We welcome people of all kinds to join the community and contribute with knowledge, skills, expertise. Everyone is welcome in our chat room (https://mattermost.coko.foundation/coko/channels/town-square).
+Kotahi is a manuscript submission system, based on the discontinued xpub-collabra project.
+It is currently under development by [eLife Pathways](https://elifepathways.org/) and is being built with [Coko Server](https://github.com/Coko-Foundation/cokoserver). We welcome people of all kinds to join the community and contribute with knowledge, skills, expertise. Everyone is welcome in our chat room (https://mattermost.coko.foundation/coko/channels/town-square).
In order to contribute to Kotahi, you're expected to follow a few sensible guidelines.
## Discuss your contribution before you build
-Please let us know about the contribution you plan to make before you start it. Either comment on a relevant existing issue, or open a new [issue](https://gitlab.coko.foundation/kotahi/kotahi/issues) if you can't find an existing one. This helps us avoid duplicating effort and to ensure contributions are likely to be accepted. You can also ask in the chat room (https://mattermost.coko.foundation/coko/channels/kotahi) if you are unsure.
+Please let us know about the contribution you plan to make before you start it. Either comment on a relevant existing issue, or open a new [issue](https://github.com/eLifePathways/Kotahi/issues) if you can't find an existing one. This helps us avoid duplicating effort and to ensure contributions are likely to be accepted. You can also ask in the chat room (https://mattermost.coko.foundation/coko/channels/kotahi) if you are unsure.
For contributions made as discussions and suggestions, you can at any time open an RFC (request for comments) in our issue tracker.
## Branches
-We maintain master as the production branch and tag it with release names. If you wish to contribute to Kotahi then you need to make a branch and then issue a pull request following this procedure:
+We maintain main as the production branch and tag it with release names. If you wish to contribute to Kotahi then you need to make a branch and then issue a pull request following this procedure:
-- Create a user account on Coko's GitLab: http://gitlab.coko.foundation
-- Clone master with `git clone git@gitlab.coko.foundation:kotahi/kotahi.git`
-- Create a new branch and work off of that. Please name the branch to sensibly identify which feature you are working on. You can push the branch to GitLab at anytime.
+- Create a user account on GitHub: https://github.com
+- Clone master with `git clone git@github.com:eLifePathways/Kotahi.git`
+- Create a new branch and work off of that. Please name the branch to sensibly identify which feature you are working on (preferably starting with the issue number). You can push the branch to GitHub at anytime.
## Getting your contributions merged
This is a two part process, first ask for comments, then ask for the changes to be merged.
-To ask for comments, generate a Merge Request (Pull Request) from the GitLab interface but do not assign this request to anyone. You do this from the Gitlab UI on your branch.
+To ask for comments, generate a Pull Request from the GitHub interface but do not assign this request to anyone. You do this from the GitHub UI on your branch.
Look at the feedback and alter your branch as necessary.
-To merge with master - generate a merge request (Pull Request). You do this from the Gitlab UI on your branch.
-We encourage feedback and discussion from as many people as possible on Merge Requests!
+To merge with master - generate a pull request. You do this from the GitHub UI on your branch.
+We encourage feedback and discussion from as many people as possible on Pull Requests!
Before merging all PRs must fulfill these three simple rules:
@@ -41,6 +41,6 @@ We use conventional commits and verify that commit messages match the pattern, y
## Bug reports, feature requests, support questions
-This is all done through GitLab using their native issue tracker
-Visit the master issue tracker for Kotahi (https://gitlab.coko.foundation/kotahi/kotahi/issues)
+This is all done through GitHub using their native issue tracker
+Visit the master issue tracker for Kotahi (https://github.com/eLifePathways/Kotahi/issues)
Tag the issue with 'support', 'bug', or 'feature' to identify the nature of your issue
diff --git a/FAQ.md b/FAQ.md
index fd284e5ac..32f804dfd 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -34,7 +34,7 @@ Click **Dashboard** in the upper right. You'll be taken to the login flow.
### How do I publish from Kotahi?
-While Kotahi deals with importing, reviewing, editing and preproduction, the final step of publishing to the web (or to print) is relegated to other tools. A wide variety of tools exist for building a static website from structured data; you may wish to use Coko Flax which is built expressly for this task.
+While Kotahi deals with importing, reviewing, editing and preproduction, the final step of publishing to the web (or to print) is relegated to other tools. A wide variety of tools exist for building a static website from structured data; you may wish to use Flax which is built expressly for this task.
Kotahi provides a GraphQL API for obtaining published article data; see [API](#api) below.
@@ -211,7 +211,7 @@ Note that publishing of review fields to hypothes.is is not yet supported.
#### Publishing Hypothesis annotations with DocMaps
-Alternatively (or as well), you can specify one or more Hypothesis annotations to create for each published manuscript, each containing whatever field or combination of fields you choose, by providing a file `config/journal/docmaps_scheme.json` on your server. This mechanism allows more complex selections of data to be published; furthermore, a [DocMap](https://docmaps.knowledgefutures.org/) will also be created at time of publishing, which can be retrieved using kotahi's public API (see below). An example file, [`config/journal/example_docmaps_scheme.json`](https://gitlab.coko.foundation/kotahi/kotahi/-/blob/main/config/journal/example_docmaps_scheme.json), is supplied.
+Alternatively (or as well), you can specify one or more Hypothesis annotations to create for each published manuscript, each containing whatever field or combination of fields you choose, by providing a file `config/journal/docmaps_scheme.json` on your server. This mechanism allows more complex selections of data to be published; furthermore, a [DocMap](https://docmaps.knowledgefutures.org/) will also be created at time of publishing, which can be retrieved using kotahi's public API (see below). An example file, [`config/journal/example_docmaps_scheme.json`](https://github.com/eLifePathways/Kotahi/blob/main/packages/server/config/journal/example_docmaps_scheme.json), is supplied.
The `docmaps_scheme.json` file specifies the _actions_ to perform when a manuscript is published, complete with participant information and directives to determine how the outputs are generated. Essentially, its structure is copied into the `actions` node of a full DocMap, expanding any templated values and replacing special directives with generated data.
@@ -264,7 +264,7 @@ Kotahi exposes a graphql API for external access. The available queries are:
- `unreviewedPreprints(token: String!, groupName: String): [Preprint!]!` returns a list of manuscripts with the `readyToEvaluate` label, for the specified group. `groupName` can be omitted if there is only one active group.
- `docmap(externalId: String!, groupName: String): String!` returns a [DocMap](https://docmaps.knowledgefutures.org/) from the specified group, representing the relationship between a given preprint (`externalId` is the preprint's URL) and related artifacts such as evaluations that have been published from Kotahi. See above for how to enable this. `groupName` can be omitted if there is only one active group.
-Consult the code [here](https://gitlab.coko.foundation/kotahi/kotahi/blob/main/server/model-manuscript/src/graphql.js) and [here](https://gitlab.coko.foundation/kotahi/kotahi/-/blob/a3f6620a553ec3f8a6c869a75021b211019280fd/server/model-docmap/src/graphql.js) for details, or the graphql playground (typically at http://localhost:4000/graphql, when your dev environment is running).
+Consult the code [here](https://github.com/eLifePathways/Kotahi/blob/main/packages/server/api/graphql/manuscript/manuscript.graphql) and [here](https://github.com/eLifePathways/Kotahi/blob/main/packages/server/api/graphql/docmap/docmap.graphql) for details, or the [graphql sandbox](https://studio.apollographql.com/sandbox/explorer), when your dev environment is running.
While these queries are publicly exposed and don't need a JWT token, the `unreviewedPreprints` query expects a `token` parameter for authentication; this must match a secret token set in the `KOTAHI_API_TOKENS` environment variable in the `.env` file. Tokens may contain any characters other than commas, and may not start or end with whitespace. Multiple tokens may be stored, separated by commas. We recommend that each token contain a human-readable identifier and a strong random string, e.g.:
@@ -332,7 +332,7 @@ To archive a group you no longer wish to have active, stop all containers, remov
### Upgrading from old versions
-When upgrading from an earlier version of Kotahi prior to 2.0, it is recommended to specify only a single group, with the _group name_ "kotahi" and the same _group type_ as previously specified for the `INSTANCE_NAME` setting. This will keep existing settings and page URLs unchanged. See [CHANGES.md](https://gitlab.coko.foundation/kotahi/kotahi/-/blob/main/CHANGES.md#2023-07-07) for instructions. You can later change or add groups as you wish.
+When upgrading from an earlier version of Kotahi prior to 2.0, it is recommended to specify only a single group, with the _group name_ "kotahi" and the same _group type_ as previously specified for the `INSTANCE_NAME` setting. This will keep existing settings and page URLs unchanged. See [CHANGES.md](https://github.com/eLifePathways/Kotahi/blob/main/CHANGES.md#2023-08-18-version-200) for instructions. You can later change or add groups as you wish.
### Configuring the Manuscripts table for your group
diff --git a/LICENSE.md b/LICENSE.md
index 9d366b781..0fa78e756 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -8,7 +8,7 @@ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLI
---
-The UI for chat ([code](https://gitlab.coko.foundation/kotahi/kotahi/tree/main/app/components/component-chat/src)) is based on parts of the [Spectrum application](https://github.com/withspectrum/spectrum). While heavily adapted and customized that part of the code also retains the original BSD-3 license below:
+The UI for chat ([code](https://github.com/eLifePathways/Kotahi/tree/main/packages/client/app/components/component-chat/src)) is based on parts of the [Spectrum application](https://github.com/withspectrum/spectrum). While heavily adapted and customized that part of the code also retains the original BSD-3 license below:
Copyright 2018 Space Program Inc.
diff --git a/README.md b/README.md
index 785a722f6..6752eab8a 100644
--- a/README.md
+++ b/README.md
@@ -28,7 +28,7 @@ Kotahi is currently under development by the [Kotahi Foundation](https://kotahi.
## Bug reporting
-To report a bug, [open a GitLab issue](https://gitlab.coko.foundation/kotahi/kotahi/-/issues/new) and use the bug-report template contained in the issue.
+To report a bug, [open a GitHub issue](https://github.com/eLifePathways/Kotahi/issues/new) and use the bug type contained in the issue.
## Deploying kotahi
@@ -36,8 +36,7 @@ You can find our deployment documentation [here](https://kotahi-dev-docs.fly.dev
## Running kotahi for development
-You can find development documentation [here](https://kotahi-dev-docs.fly.dev/docs/development/Getting%20started).
-Documentation for underlying coko libraries can be found [here](https://coko-dev-docs.fly.dev/).
+You can find development documentation [here](https://kotahi-dev-docs.fly.dev/docs/development/Getting%20started).
## Further info
diff --git a/package.json b/package.json
index a66e1db42..9ab36cdca 100644
--- a/package.json
+++ b/package.json
@@ -5,7 +5,7 @@
"description": "Kotahi - open journals",
"repository": {
"type": "git",
- "url": "https://gitlab.coko.foundation/kotahi/kotahi"
+ "url": "https://github.com/eLifePathways/Kotahi"
},
"license": "MIT",
"scripts": {
diff --git a/packages/client/app/components/component-cms-manager/src/queries.js b/packages/client/app/components/component-cms-manager/src/queries.js
index b096432b7..30d9f33cb 100644
--- a/packages/client/app/components/component-cms-manager/src/queries.js
+++ b/packages/client/app/components/component-cms-manager/src/queries.js
@@ -304,6 +304,12 @@ export const deleteFileMutation = gql`
}
`
+export const generateNewCoarAuthTokenMutation = gql`
+ mutation ($name: String!, $groupId: ID!) {
+ generateNewToken(name: $name, groupId: $groupId)
+ }
+`
+
export const updateCollectionMutation = gql`
mutation ($id: ID!, $input: PublishCollectionInput!) {
updateCollection(id: $id, input: $input) {
diff --git a/packages/client/app/components/component-config-manager/src/ConfigManagerForm.js b/packages/client/app/components/component-config-manager/src/ConfigManagerForm.js
index e3741fe0a..4e7d14560 100644
--- a/packages/client/app/components/component-config-manager/src/ConfigManagerForm.js
+++ b/packages/client/app/components/component-config-manager/src/ConfigManagerForm.js
@@ -4,7 +4,7 @@
import React, { useMemo, useRef, useState } from 'react'
import Form from '@rjsf/core'
import { useTranslation } from 'react-i18next'
-import styled from 'styled-components'
+import styled, { css } from 'styled-components'
import { isEqual } from 'lodash'
import { grid } from '@coko/client'
import {
@@ -20,6 +20,7 @@ import {
Heading,
SectionContent,
HiddenTabs,
+ Alert,
} from '../../shared'
import { color, space } from '../../../theme'
import EmailTemplatesPage from '../../component-email-templates/src/EmailTemplatesPage'
@@ -136,6 +137,13 @@ const EmailsTabWrapper = styled(StyledSectionContent)`
// TODO Improve on this hardcoded hack to hide the "Publishing" heading.
const StyledWrapper = styled.div`
+ ${p =>
+ p.$showGap &&
+ css`
+ display: grid;
+ gap: ${grid(2)};
+ `}
+
/* stylelint-disable-next-line selector-id-pattern */
#form-integrations_publishing > legend:nth-of-type(1) {
display: ${p => (p.$hideFirstLegend ? 'none' : 'block')};
@@ -167,14 +175,30 @@ const FieldTemplate = props => {
'form-emailNotifications_emailNotification_advancedSettings_requireTLS',
]
+ const alertFields = [
+ 'form-integrationsAndPublishing_integrations_coarNotify_repoIpAddress',
+ ]
+
const hideLabel = suppressedLabels.includes(id)
const hideDescription = supressedDescriptions.includes(id)
+ const showWarning = alertFields.includes(id)
+
const getFieldName = key => description._owner.key === key
// eslint-disable-next-line no-nested-ternary
return !showInstanceType ? (
!getFieldName('instanceName') ? (
-
+
+ {showWarning && (
+
+ )}