Updating GI test running from main

.github/workflows/tests.yml

@@ -2,7 +2,7 @@ name: Tests
 
 on:
   push:
-    branches: [ main, dev ]
+    branches: [ main, dev, staging, production ]
   pull_request:
     branches: [ main, dev, staging, production ]
   schedule:
@@ -107,3 +107,22 @@ jobs:
         run: |
           chmod +x run-js-tests.sh
           bash run-js-tests.sh
+
+      - name: Create test data directory
+        run: mkdir -p test-data
+
+      - name: Copy CSV file
+        run: cp tests/e2e/works_collections_loggedIn_staging.csv test-data/
+
+      - name: Execute Ghost Inspector tests
+        if: github.ref == 'refs/heads/staging' || github.ref == 'refs/heads/production'
+        env:
+          GHOST_INSPECTOR_API_KEY: ${{ secrets.GHOST_INSPECTOR_API_KEY }}
+        uses: docker://ghostinspector/cli
+        with:
+          args: |
+            suite execute 66a3a33b333cf823ad8fff8a 6815258158d7ce73a10ca70b \
+            --startUrl "https://works.hcommons-staging.org" \
+            --dataFile "/github/workspace/test-data/works_collections_loggedIn_staging.csv" \
+            --errorOnFail \
+            --errorOnScreenshotFail

assets/js/invenio_app_rdm/overridableRegistry/requests/actions/RequestActions.js

@@ -28,9 +28,9 @@ const RequestActions = ({ request, actions, size }) => {
 
   // FIXME: This is a temporary fix to hide the cancel action for
   // people other than the requester. This should be handled on the server side.
-  if ( !request.expanded.created_by.is_current_user ) {
-    actions = actions.filter(action => action !== "cancel");
-  }
+  // if ( !request.expanded.created_by.is_current_user ) {
+  //   actions = actions.filter(action => action !== "cancel");
+  // }
 
   return (
       <MediaContextProvider>

assets/less/site/collections/grid.overrides

@@ -70,6 +70,13 @@
   }
 }
 
+.communities-detail-body.ui.grid {
+  .communities-detail-about.column,
+  .communities-detail-curation.column {
+    padding-top: 1.5rem;
+  }
+}
+
 .ui.form {
   #rdm-deposit-form {
     .ui.grid {

docs/source/developing/source_control.md

@@ -33,10 +33,18 @@ When a developer needs to make changes to the codebase, they should create a new
 
 Changes should be merged back into `main` as often as possible, and the temporary branches deleted. These merges should be performed when a developer is ready to deploy the changes to the staging server for testing. This should generally be done *after* the appropriate tests have been written and are passing. Merges should also represent a single completed change (feature or fix). Developers should, though, think in terms of small, incremental changes and merge often.
 
-Merging to `main` should be done via pull request, and the merge only accepted if the newly added tests are present and passing. This ensures that the `main` branch is always in a deployable state and ready for incoming merges by other developers. Merges should be performed using the squash merge strategy (the equivalent of `git merge --squash <branch>`). This combines all of the incoming changes into a single commit, making the commit history cleaner and easier to read.
+Merging to `main` should be done via pull request, and the merge only accepted if the newly added tests are present and passing. This ensures that the `main` branch is always in a deployable state and ready for incoming merges by other developers.
+
+```{note}
+Merges into `main` should be performed using the `squash` merge strategy (the equivalent of `git merge --squash <branch>`). This combines all of the incoming changes into a single commit, making the commit history cleaner and easier to read.
+```
 
 No commits should be made directly to the `staging` or `production` branches. All changes should be made to the `main` branch and then merged into `staging` and `production` via pull requests. This is especially important because changes pushed to `staging` and `production` branches will automatically trigger rebuilding of the stanging or production containers and the deployment of the updated containers to the respective servers.
 
+```{note}
+Pull requests to staging and production should be merged using the `rebase` merge strategy, so that the commit history for these branches is kept clean and identical to the `main` branch.
+```
+
 ### Commit strategy
 
 Developers should make frequent commits to their working branch. These may be as small and granular as the developer wishes since many incremental commits allow easy rollback to specific points in the development history. Such commits should be given descriptive names and commit messages that would allow quick identification of the changes. These commits will be squashed into a single commit when merged into `main`.

site/kcworks/assets/semantic-ui/js/collections/community/header.js

@@ -160,7 +160,7 @@ const CommunityDetailsHeader = ({
             {visibility == "restricted" && (
               <div className="row">
                 <div className="column">
-                  <div className="rel-ml-1">
+                  <div className="rel-ml-0 rel-mb-1">
                     <AccessStatusLabel />
                   </div>
                   <div className="mobile only rel-mb-1">

templates/semantic-ui/invenio_communities/details/about/index.html

@@ -26,7 +26,7 @@ <h2>{{ _("About") }}</h2>
   <div
     class="right floated thirteen wide computer thirteen wide tablet sixteen wide mobile column communities-detail-body communities-detail-about"
   >
-    <div clas="communities-detail-about-text">
+    <div class="communities-detail-about-text">
     {{ community.metadata.page | safe }}
     </div>
 

tests/e2e/works_collections_loggedIn_production.csv

@@ -0,0 +1,2 @@
+base-url,collection-item-uuid
+https://works.hcommons.org,95a6e518-9809-4be3-971e-fef2c98de42d

tests/e2e/works_collections_loggedIn_staging.csv

@@ -0,0 +1,2 @@
+base-url,collection-item-uuid,member-result-email
+https://works.hcommons-staging.org,95a6e518-9809-4be3-971e-fef2c98de42d,ghosthc@email.ghostinspector.com