Merge branch 'main' into w2p-97257_limit-edit-item-modal-results

.eslintrc.json

@@ -6,7 +6,8 @@
     "eslint-plugin-import",
     "eslint-plugin-jsdoc",
     "eslint-plugin-deprecation",
-    "eslint-plugin-unused-imports"
+    "unused-imports",
+    "eslint-plugin-lodash"
   ],
   "overrides": [
     {
@@ -202,7 +203,13 @@
         "deprecation/deprecation": "warn",
 
         "import/order": "off",
-        "import/no-deprecated": "warn"
+        "import/no-deprecated": "warn",
+        "import/no-namespace": "error",
+        "unused-imports/no-unused-imports": "error",
+        "lodash/import-scope": [
+          "error",
+          "method"
+        ]
       }
     },
     {

.github/pull_request_template.md

@@ -1,7 +1,7 @@
 ## References
 _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)
+* Fixes #`issue-number` (if this fixes an issue ticket)
+* Requires DSpace/DSpace#`pr-number` (if a REST API PR is required to test this)
 
 ## Description
 Short summary of changes (1-2 sentences).
@@ -19,8 +19,10 @@ List of changes in this PR:
 _This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!_
 
 - [ ] 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 passes [ESLint](https://eslint.org/) validation using `yarn lint`
+- [ ] My PR doesn't introduce circular dependencies (verified via `yarn check-circ-deps`)
 - [ ] 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 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.
+- [ ] If my PR includes new libraries/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.
+- [ ] If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
+- [ ] If my PR fixes an issue ticket, I've [linked them together](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue).

.github/workflows/build.yml

@@ -6,34 +6,39 @@ name: Build
 # Run this Build for all pushes / PRs to current branch
 on: [push, pull_request]
 
+permissions:
+  contents: read  #  to fetch code (actions/checkout)
+
 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_HOST: 127.0.0.1
       DSPACE_REST_PORT: 8080
       DSPACE_REST_NAMESPACE: '/server'
       DSPACE_REST_SSL: false
+      # Spin up UI on 127.0.0.1 to avoid host resolution issues in e2e tests with Node 18+
+      DSPACE_UI_HOST: 127.0.0.1
       # When Chrome version is specified, we pin to a specific version of Chrome
       # Comment this out to use the latest release
       #CHROME_VERSION: "90.0.4430.212-1"
     strategy:
       # Create a matrix of Node versions to test against (in parallel)
       matrix:
-        node-version: [14.x, 16.x]
+        node-version: [16.x, 18.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@v2
+        uses: actions/checkout@v3
 
       # https://github.com/actions/setup-node
       - name: Install Node.js ${{ matrix.node-version }}
-        uses: actions/setup-node@v2
+        uses: actions/setup-node@v3
         with:
           node-version: ${{ matrix.node-version }}
 
@@ -58,7 +63,7 @@ jobs:
         id: yarn-cache-dir-path
         run: echo "::set-output name=dir::$(yarn cache dir)"
       - name: Cache Yarn dependencies
-        uses: actions/cache@v2
+        uses: actions/cache@v3
         with:
           # Cache entire Yarn cache directory (see previous step)
           path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
@@ -85,7 +90,7 @@ jobs:
       # Upload coverage reports to Codecov (for one version of Node only)
       # https://github.com/codecov/codecov-action
       - name: Upload coverage to Codecov.io
-        uses: codecov/codecov-action@v2
+        uses: codecov/codecov-action@v3
         if: matrix.node-version == '16.x'
 
       # Using docker-compose start backend using CI configuration
@@ -100,7 +105,7 @@ jobs:
       # https://github.com/cypress-io/github-action
       # (NOTE: to run these e2e tests locally, just use 'ng e2e')
       - name: Run e2e tests (integration tests)
-        uses: cypress-io/github-action@v2
+        uses: cypress-io/github-action@v4
         with:
           # Run tests in Chrome, headless mode
           browser: chrome
@@ -109,14 +114,14 @@ jobs:
           start: yarn run serve:ssr
           # Wait for backend & frontend to be available
           # NOTE: We use the 'sites' REST endpoint to also ensure the database is ready
-          wait-on: http://localhost:8080/server/api/core/sites, http://localhost:4000
+          wait-on: http://127.0.0.1:8080/server/api/core/sites, http://127.0.0.1:4000
           # Wait for 2 mins max for everything to respond
           wait-on-timeout: 120
 
       # Cypress always creates a video of all e2e tests (whether they succeeded or failed)
       # Save those in an Artifact
       - name: Upload e2e test videos to Artifacts
-        uses: actions/upload-artifact@v2
+        uses: actions/upload-artifact@v3
         if: always()
         with:
           name: e2e-test-videos
@@ -125,7 +130,7 @@ jobs:
       # If e2e tests fail, Cypress creates a screenshot of what happened
       # Save those in an Artifact
       - name: Upload e2e test failure screenshots to Artifacts
-        uses: actions/upload-artifact@v2
+        uses: actions/upload-artifact@v3
         if: failure()
         with:
           name: e2e-test-screenshots
@@ -144,7 +149,7 @@ jobs:
         run: |
           nohup yarn run serve:ssr &
           printf 'Waiting for app to start'
-          until curl --output /dev/null --silent --head --fail http://localhost:4000/home; do
+          until curl --output /dev/null --silent --head --fail http://127.0.0.1:4000/home; do
             printf '.'
             sleep 2
           done
@@ -155,7 +160,7 @@ jobs:
       # This step also prints entire HTML of homepage for easier debugging if grep fails.
       - name: Verify SSR (server-side rendering)
         run: |
-          result=$(wget -O- -q http://localhost:4000/home)
+          result=$(wget -O- -q http://127.0.0.1:4000/home)
           echo "$result"
           echo "$result" | grep -oE "<meta name=\"title\" [^>]*>" | grep DSpace
 

.github/workflows/codescan.yml

@@ -0,0 +1,49 @@
+# DSpace CodeQL code scanning configuration for GitHub
+# https://docs.github.com/en/code-security/code-scanning
+#
+# NOTE: Code scanning must be run separate from our default build.yml
+# because CodeQL requires a fresh build with all tests *disabled*.
+name: "Code Scanning"
+
+# Run this code scan for all pushes / PRs to main branch. Also run once a week.
+on:
+  push:
+    branches: [ main ]
+  pull_request:
+    branches: [ main ]
+    # Don't run if PR is only updating static documentation
+    paths-ignore:
+      - '**/*.md'
+      - '**/*.txt'
+  schedule:
+    - cron: "37 0 * * 1"
+
+jobs:
+  analyze:
+    name: Analyze Code
+    runs-on: ubuntu-latest
+    # Limit permissions of this GitHub action. Can only write to security-events
+    permissions:
+      actions: read
+      contents: read
+      security-events: write
+
+    steps:
+      # https://github.com/actions/checkout
+      - name: Checkout repository
+        uses: actions/checkout@v3
+
+      # Initializes the CodeQL tools for scanning.
+      # https://github.com/github/codeql-action
+      - name: Initialize CodeQL
+        uses: github/codeql-action/init@v2
+        with:
+          languages: javascript
+
+      # Autobuild attempts to build any compiled languages
+      - name: Autobuild
+        uses: github/codeql-action/autobuild@v2
+
+      # Perform GitHub Code Scanning.
+      - name: Perform CodeQL Analysis
+        uses: github/codeql-action/analyze@v2

.github/workflows/docker.yml

@@ -12,6 +12,9 @@ on:
       - 'dspace-**'
   pull_request:
 
+permissions:
+  contents: read  #  to fetch code (actions/checkout)
+
 jobs:
   docker:
     # Ensure this job never runs on forked repos. It's only executed for 'dspace/dspace-angular'
@@ -39,11 +42,11 @@ jobs:
     steps:
       # https://github.com/actions/checkout
       - name: Checkout codebase
-        uses: actions/checkout@v2
+        uses: actions/checkout@v3
 
       # https://github.com/docker/setup-buildx-action
       - name: Setup Docker Buildx
-        uses: docker/setup-buildx-action@v1
+        uses: docker/setup-buildx-action@v2
 
       # https://github.com/docker/setup-qemu-action
       - name: Set up QEMU emulation to build for multiple architectures
@@ -53,7 +56,7 @@ jobs:
       - name: Login to DockerHub
         # Only login if not a PR, as PRs only trigger a Docker build and not a push
         if: github.event_name != 'pull_request'
-        uses: docker/login-action@v1
+        uses: docker/login-action@v2
         with:
           username: ${{ secrets.DOCKER_USERNAME }}
           password: ${{ secrets.DOCKER_ACCESS_TOKEN }}
@@ -65,7 +68,7 @@ jobs:
       # Get Metadata for docker_build step below
       - name: Sync metadata (tags, labels) from GitHub to Docker for 'dspace-angular' image
         id: meta_build
-        uses: docker/metadata-action@v3
+        uses: docker/metadata-action@v4
         with:
           images: dspace/dspace-angular
           tags: ${{ env.IMAGE_TAGS }}
@@ -74,7 +77,7 @@ jobs:
       # https://github.com/docker/build-push-action
       - name: Build and push 'dspace-angular' image
         id: docker_build
-        uses: docker/build-push-action@v2
+        uses: docker/build-push-action@v3
         with:
           context: .
           file: ./Dockerfile

.github/workflows/issue_opened.yml

@@ -5,25 +5,22 @@ on:
   issues:
     types: [opened]
 
+permissions: {}
 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
+    # See https://github.com/actions/add-to-project
+    - name: Add issue to triage 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
+      uses: actions/[email protected]
       # 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
+      # It must be created/recreated manually via a personal access token with admin:org, project, public_repo 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-token: ${{ secrets.TRIAGE_PROJECT_TOKEN }}
+        project-url: https://github.com/orgs/DSpace/projects/24

.github/workflows/label_merge_conflicts.yml

@@ -5,21 +5,32 @@ name: Check for merge conflicts
 # NOTE: This means merge conflicts are only checked for when a PR is merged to main.
 on:
   push:
-    branches:
-      - main
+    branches: [ main ]
+  # So that the `conflict_label_name` is removed if conflicts are resolved,
+  # we allow this to run for `pull_request_target` so that github secrets are available.
+  pull_request_target:
+    types: [ synchronize ]
+
+permissions: {}
 
 jobs:
   triage:
+    # Ensure this job never runs on forked repos. It's only executed for 'dspace/dspace-angular'
+    if: github.repository == 'dspace/dspace-angular'
     runs-on: ubuntu-latest
+    permissions:
+      pull-requests: write
     steps:
-      # See: https://github.com/mschilde/auto-label-merge-conflicts/
+      # See: https://github.com/prince-chrismc/label-merge-conflicts-action
       - name: Auto-label PRs with merge conflicts
-        uses: mschilde/auto-label-merge-conflicts@v2.0
+        uses: prince-chrismc/label-merge-conflicts-action@v2
         # 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
+          conflict_label_name: 'merge conflict'
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          conflict_comment: |
+            Hi @${author},
+            Conflicts have been detected against the base branch.
+            Please [resolve these conflicts](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts) as soon as you can. Thanks!

CONTRIBUTING.md

@@ -0,0 +1,46 @@
+# How to Contribute
+
+DSpace is a community built and supported project. We do not have a centralized development or support team, but have a dedicated group of volunteers who help us improve the software, documentation, resources, etc.
+
+* [Contribute new code via a Pull Request](#contribute-new-code-via-a-pull-request)
+* [Contribute documentation](#contribute-documentation)
+* [Help others on mailing lists or Slack](#help-others-on-mailing-lists-or-slack)
+* [Join a working or interest group](#join-a-working-or-interest-group)
+
+## Contribute new code via a Pull Request
+
+We accept [GitHub Pull Requests (PRs)](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork) at any time from anyone.
+Contributors to each release are recognized in our [Release Notes](https://wiki.lyrasis.org/display/DSDOC7x/Release+Notes).
+
+Code Contribution Checklist
+- [ ] PRs _should_ be smaller in size (ideally less than 1,000 lines of code, not including comments & tests)
+- [ ] PRs **must** pass [ESLint](https://eslint.org/) validation using `yarn lint`
+- [ ] PRs **must** not introduce circular dependencies (verified via `yarn check-circ-deps`)
+- [ ] PRs **must** include [TypeDoc](https://typedoc.org/) comments for _all new (or modified) public methods and classes_. Large or complex private methods should also have TypeDoc.
+- [ ] PRs **must** pass all automated pecs/tests and includes new/updated specs or tests based on the [Code Testing Guide](https://wiki.lyrasis.org/display/DSPACE/Code+Testing+Guide).
+- [ ] If a PR includes new libraries/dependencies (in `package.json`), then their software licenses **must** align with the [DSpace BSD License](https://github.com/DSpace/dspace-angular/blob/main/LICENSE) based on the [Licensing of Contributions](https://wiki.lyrasis.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-LicensingofContributions) documentation.
+- [ ] Basic technical documentation _should_ be provided for any new features or configuration, either in the PR itself or in the DSpace Wiki documentation.
+- [ ] If a PR fixes an issue ticket, please [link them together](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue).
+
+Additional details on the code contribution process can be found in our [Code Contribution Guidelines](https://wiki.lyrasis.org/display/DSPACE/Code+Contribution+Guidelines)
+
+## Contribute documentation
+
+DSpace Documentation is a collaborative effort in a shared Wiki. The latest documentation is at https://wiki.lyrasis.org/display/DSDOC7x 
+
+If you find areas of the DSpace Documentation which you wish to improve, please request a Wiki account by emailing [email protected].
+Once you have an account setup, contact @tdonohue (via [Slack](https://wiki.lyrasis.org/display/DSPACE/Slack) or email) for access to edit our Documentation.
+
+## Help others on mailing lists or Slack
+
+DSpace has our own [Slack](https://wiki.lyrasis.org/display/DSPACE/Slack) community and [Mailing Lists](https://wiki.lyrasis.org/display/DSPACE/Mailing+Lists) where discussions take place and questions are answered.
+Anyone is welcome to join and help others. We just ask you to follow our [Code of Conduct](https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx) (adopted via LYRASIS).
+
+## Join a working or interest group
+
+Most of the work in building/improving DSpace comes via [Working Groups](https://wiki.lyrasis.org/display/DSPACE/DSpace+Working+Groups) or [Interest Groups](https://wiki.lyrasis.org/display/DSPACE/DSpace+Interest+Groups).
+
+All working/interest groups are open to anyone to join and participate.  A few key groups to be aware of include:
+
+* [DSpace 7 Working Group](https://wiki.lyrasis.org/display/DSPACE/DSpace+7+Working+Group) - This is the main (mostly volunteer) development team. We meet weekly to review our current development [project board](https://github.com/orgs/DSpace/projects), assigning tickets and/or PRs.
+* [DSpace Community Advisory Team (DCAT)](https://wiki.lyrasis.org/display/cmtygp/DSpace+Community+Advisory+Team) - This is an interest group for repository managers/administrators. We meet monthly to discuss DSpace, share tips & provide feedback back to developers.