New Finnish keys January 2021

.codecov.yml

@@ -0,0 +1,28 @@
+# DSpace configuration for Codecov.io coverage reports
+# These override the default YAML settings at
+# https://docs.codecov.io/docs/codecov-yaml#section-default-yaml
+# Can be validated via instructions at:
+# https://docs.codecov.io/docs/codecov-yaml#validate-your-repository-yaml
+
+# Settings related to code coverage analysis
+coverage:
+  status:
+    # Configuration for project-level checks. This checks how the PR changes overall coverage.
+    project:
+      default:
+        # For each PR, auto compare coverage to previous commit.
+        # Require that overall (project) coverage does NOT drop more than 0.5%
+        target: auto
+        threshold: 0.5%
+    # Configuration for patch-level checks. This checks the relative coverage of the new PR code ONLY.
+    patch:
+      default:
+         # Enable informational mode, which just provides info to reviewers & always passes
+         # https://docs.codecov.io/docs/commit-status#section-informational
+         informational: true
+
+# Turn PR comments "off". This feature adds the code coverage summary as a
+# comment on each PR. See https://docs.codecov.io/docs/pull-request-comments
+# However, this same info is available from the Codecov checks in the PR's
+# "Checks" tab in GitHub. So, the comment is unnecessary.
+comment: false

.editorconfig

@@ -12,3 +12,6 @@ trim_trailing_whitespace = true
 [*.md]
 insert_final_newline = false
 trim_trailing_whitespace = false
+
+[*.ts]
+quote_type = single

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,22 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: bug, needs triage
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is. Include the version(s) of DSpace where you've seen this problem & what *web browser* you were using. Link to examples if they are public.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Do this
+2. Then this...
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Related work**
+Link to any related tickets or PRs here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest a new feature for this project
+title: ''
+labels: new feature, needs triage
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives or workarounds you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/disabled-workflows/pull_request_opened.yml

@@ -0,0 +1,26 @@
+# This workflow runs whenever a new pull request is created
+# TEMPORARILY DISABLED. Unfortunately this doesn't work for PRs created from forked repositories (which is how we tend to create PRs).
+# There is no known workaround yet. See https://git.blink-cf.community/t/how-to-use-github-token-for-prs-from-forks/16818
+name: Pull Request opened
+
+# Only run for newly opened PRs against the "main" branch
+on: 
+  pull_request:
+    types: [opened]
+    branches: 
+      - main
+
+jobs:
+  automation:
+    runs-on: ubuntu-latest
+    steps:
+    # Assign the PR to whomever created it. This is useful for visualizing assignments on project boards
+    # See https://github.com/marketplace/actions/pull-request-assigner
+    - name: Assign PR to creator
+      uses: thomaseizinger/assign-pr-creator-action@v1.0.0
+      # Note, this authentication token is created automatically
+      # See: https://docs.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token
+      with:
+        repo-token: ${{ secrets.GITHUB_TOKEN }}
+      # Ignore errors. It is possible the PR was created by someone who cannot be assigned
+      continue-on-error: true

.github/pull_request_template.md

@@ -1,7 +1,7 @@
 ## References
-_Add references/links to any related tickets or PRs. These may include:_
-* Link to [Angular issue or PR](https://github.com/DSpace/dspace-angular/issues) related to this PR, if any
-* Link to [JIRA](https://jira.lyrasis.org/projects/DS/summary) ticket(s), if any
+_Add references/links to any related issues or PRs. These may include:_
+* Fixes #[issue-number]
+* Requires DSpace/DSpace#[pr-number] (if a REST API PR is required to test this)
 
 ## Description
 Short summary of changes (1-2 sentences).
@@ -20,9 +20,7 @@ _This checklist provides a reminder of what we are going to look for when review
 
 - [ ] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
 - [ ] My PR passes [TSLint](https://palantir.github.io/tslint/) validation using `yarn run lint`
+- [ ] My PR doesn't introduce circular dependencies
 - [ ] My PR includes [TypeDoc](https://typedoc.org/) comments for _all new (or modified) public methods and classes_. It also includes TypeDoc for large or complex private methods.
-- [ ] My PR passes all specs/tests and includes new/updated specs for any bug fixes, improvements or new features. A few reminders about what constitutes good tests:
-    * Include tests for different user types (if behavior differs), including: (1) Anonymous user, (2) Logged in user (non-admin), and (3) Administrator.
-    * Include tests for error scenarios, e.g. when errors/warnings should appear (or buttons should be disabled).
-    * For bug fixes, include a test that reproduces the bug and proves it is fixed. For clarity, it may be useful to provide the test in a separate commit from the bug fix.
-- [ ] If my PR includes new, third-party dependencies (in `package.json`), I've made sure their licenses align with the [DSpace BSD License](https://github.com/DSpace/DSpace/blob/master/LICENSE) based on the [Licensing of Contributions](https://wiki.lyrasis.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-LicensingofContributions) documentation.
+- [ ] My PR passes all specs/tests and includes new/updated specs or tests based on the [Code Testing Guide](https://wiki.lyrasis.org/display/DSPACE/Code+Testing+Guide).
+- [ ] If my PR includes new, third-party dependencies (in `package.json`), I've made sure their licenses align with the [DSpace BSD License](https://github.com/DSpace/DSpace/blob/main/LICENSE) based on the [Licensing of Contributions](https://wiki.lyrasis.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-LicensingofContributions) documentation.

.github/workflows/build.yml

@@ -0,0 +1,87 @@
+# DSpace Continuous Integration/Build via GitHub Actions
+# Concepts borrowed from
+# https://docs.github.com/en/free-pro-team@latest/actions/guides/building-and-testing-nodejs
+name: Build
+
+# Run this Build for all pushes / PRs to current branch
+on: [push, pull_request]
+
+jobs:
+  tests:
+    runs-on: ubuntu-latest
+    env:
+      # The ci step will test the dspace-angular code against DSpace REST.
+      # Direct that step to utilize a DSpace REST service that has been started in docker.
+      DSPACE_REST_HOST: localhost
+      DSPACE_REST_PORT: 8080
+      DSPACE_REST_NAMESPACE: '/server'
+      DSPACE_REST_SSL: false
+    strategy:
+      # Create a matrix of Node versions to test against (in parallel)
+      matrix:
+        node-version: [10.x, 12.x]
+      # Do NOT exit immediately if one matrix job fails
+      fail-fast: false
+    # These are the actual CI steps to perform per job
+    steps:
+      # https://github.com/actions/checkout
+      - name: Checkout codebase
+        uses: actions/checkout@v1
+
+      # https://github.com/actions/setup-node
+      - name: Install Node.js ${{ matrix.node-version }}
+        uses: actions/setup-node@v1
+        with:
+          node-version: ${{ matrix.node-version }}
+
+      - name: Install latest Chrome (for e2e tests)
+        run: |
+          sudo apt-get update
+          sudo apt-get --only-upgrade install google-chrome-stable -y
+          google-chrome --version
+
+      # https://github.com/actions/cache/blob/main/examples.md#node---yarn
+      - name: Get Yarn cache directory
+        id: yarn-cache-dir-path
+        run: echo "::set-output name=dir::$(yarn cache dir)"
+      - name: Cache Yarn dependencies
+        uses: actions/cache@v2
+        with:
+          # Cache entire Yarn cache directory (see previous step)
+          path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
+          # Cache key is hash of yarn.lock. Therefore changes to yarn.lock will invalidate cache
+          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
+          restore-keys: ${{ runner.os }}-yarn-
+
+      - name: Install Yarn dependencies
+        run: yarn install --frozen-lockfile
+
+      - name: Run lint
+        run: yarn run lint
+
+      - name: Run build
+        run: yarn run build:prod
+
+      - name: Run specs (unit tests)
+        run: yarn run test:headless
+
+      # NOTE: Angular CLI only supports code coverage for specs. See https://github.com/angular/angular-cli/issues/6286
+      # Upload coverage reports to Codecov (for Node v12 only)
+      # https://github.com/codecov/codecov-action
+      - name: Upload coverage to Codecov.io
+        uses: codecov/codecov-action@v1
+        if: matrix.node-version == '12.x'
+
+      # Using docker-compose start backend using CI configuration
+      # and load assetstore from a cached copy
+      - name: Start DSpace REST Backend via Docker (for e2e tests)
+        run: |
+          docker-compose -f ./docker/docker-compose-ci.yml up -d
+          docker-compose -f ./docker/cli.yml -f ./docker/cli.assetstore.yml run --rm dspace-cli
+          docker container ls
+
+      - name: Run e2e tests (integration tests)
+        run: yarn run e2e:ci
+
+      - name: Shutdown Docker containers
+        run: docker-compose -f ./docker/docker-compose-ci.yml down

.github/workflows/issue_opened.yml

@@ -0,0 +1,29 @@
+# This workflow runs whenever a new issue is created
+name: Issue opened
+
+on: 
+  issues:
+    types: [opened]
+
+jobs:
+  automation:
+    runs-on: ubuntu-latest
+    steps:
+    # Add the new issue to a project board, if it needs triage
+    # See https://github.com/marketplace/actions/create-project-card-action
+    - name: Add issue to project board
+      # Only add to project board if issue is flagged as "needs triage" or has no labels
+      # NOTE: By default we flag new issues as "needs triage" in our issue template
+      if: (contains(github.event.issue.labels.*.name, 'needs triage') || join(github.event.issue.labels.*.name) == '')
+      uses: technote-space/create-project-card-action@v1
+      # Note, the authentication token below is an ORG level Secret. 
+      # It must be created/recreated manually via a personal access token with "public_repo" and "admin:org" permissions
+      # See: https://docs.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token#permissions-for-the-github_token
+      # This is necessary because the "DSpace Backlog" project is an org level project (i.e. not repo specific)
+      with:
+        GITHUB_TOKEN: ${{ secrets.ORG_PROJECT_TOKEN }}
+        PROJECT: DSpace Backlog
+        COLUMN: Triage
+        CHECK_ORG_PROJECT: true
+      # Ignore errors
+      continue-on-error: true

.github/workflows/label_merge_conflicts.yml

@@ -0,0 +1,25 @@
+# This workflow checks open PRs for merge conflicts and labels them when conflicts are found
+name: Check for merge conflicts
+
+# Run whenever the "main" branch is updated
+# NOTE: This means merge conflicts are only checked for when a PR is merged to main.
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  triage:
+    runs-on: ubuntu-latest
+    steps:
+      # See: https://github.com/mschilde/auto-label-merge-conflicts/
+      - name: Auto-label PRs with merge conflicts
+        uses: mschilde/auto-label-merge-conflicts@v2.0
+        # Add "merge conflict" label if a merge conflict is detected. Remove it when resolved.
+        # Note, the authentication token is created automatically
+        # See: https://docs.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token
+        with:
+          CONFLICT_LABEL_NAME: 'merge conflict'
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        # Ignore errors
+        continue-on-error: true

.gitignore

@@ -39,3 +39,4 @@ package-lock.json
 .java-version
 
 .env
+/nbproject/

README.md

@@ -1,4 +1,4 @@
-[![Build Status](https://travis-ci.org/DSpace/dspace-angular.svg?branch=master)](https://travis-ci.org/DSpace/dspace-angular) [![Coverage Status](https://coveralls.io/repos/github/DSpace/dspace-angular/badge.svg?branch=master)](https://coveralls.io/github/DSpace/dspace-angular?branch=master) [![Universal Angular](https://img.shields.io/badge/universal-angular2-brightgreen.svg?style=flat)](https://github.com/angular/universal)
+[![Build Status](https://github.com/DSpace/dspace-angular/workflows/Build/badge.svg?branch=main)](https://github.com/DSpace/dspace-angular/actions?query=workflow%3ABuild) [![Coverage Status](https://codecov.io/gh/DSpace/dspace-angular/branch/main/graph/badge.svg)](https://codecov.io/gh/DSpace/dspace-angular) [![Universal Angular](https://img.shields.io/badge/universal-angular2-brightgreen.svg?style=flat)](https://github.com/angular/universal)
 
 dspace-angular
 ==============
@@ -104,11 +104,12 @@ DSPACE_REST_SSL # Whether the angular REST uses SSL [true/false]
 
 The same settings can also be overwritten by setting system environment variables instead, E.g.:
 ```bash 
-export DSPACE_HOST=https://dspace7.4science.cloud/server
+export DSPACE_HOST=dspace7.4science.cloud
 ```
 
 The priority works as follows: **environment variable** overrides **variable in `.env` file** overrides **`environment.(prod, dev or test).ts`** overrides **`environment.common.ts`**
 
+These configuration sources are collected **at build time**, and written to `src/environments/environment.ts`.  At runtime the configuration is fixed, and neither `.env` nor the process' environment will be consulted.
 
 #### Using environment variables in code
 To use environment variables in a UI component, use:
@@ -134,14 +135,14 @@ To build the app for production and start the server run:
 ```bash
 yarn start
 ```
+This will run the application in an instance of the Express server, which is included.
 
 If you only want to build for production, without starting, run:
 
 ```bash
 yarn run build:prod
 ```
-
-This will build the application and put the result in the `dist` folder
+This will build the application and put the result in the `dist` folder.  You can copy this folder to wherever you need it for your application server.  If you will be using the built-in Express server, you'll also need a copy of the `node_modules` folder tucked inside your copy of `dist`.
 
 
 ### Running the application with Docker