administrator actions in 7.2

[Bill Tantzen]

Configuration question I guess.

I am a member of the Administrators group.  However when I log in, most of the administrator actions on the sidebar are not available to me (for instance, create a community/collection, access control, administer workflow etc).  The only options available are create an item, and import/export metadata.  All those actions are available to me upon login in our current version, 5.10.

Can you point me to where this is configured in 7.2? Or better yet to the documentation (if it exists yet)?

Thanks a million,

~~Bill

--

Human wheels spin round and round
While the clock keeps the pace... -- John Mellencamp
________________________________________________________________
Bill Tantzen    University of Minnesota Libraries
612-626-9949 (U of M)    612-325-1777 (cell)

[Tim Donohue]

Hi Bill,

Those side menus should be checking which groups you are a member of automatically (by querying the backend/REST API when you login). They are coded to do so in the AdminSidebar component, starting around here: https://github.com/DSpace/dspace-angular/blob/main/src/app/admin/admin-sidebar/admin-sidebar.component.ts#L133

If you look at each of the sections, they are coded to detect if you are a SiteAdmin (i.e. in "Administrator" group), or a Community or Collection admin (of any community/collection), and based on your permissions, it'll show appropriate menus.  So, for a SiteAdmin, all menus should be displayed.

I doubt​ it's that code that's to blame...as this is the first time I've heard of this behavior & it seems to work fine on demo7.dspace.org.  You may want to look around more closely at your logs (in case any error is occurring), and even look at whether the UI is throwing a client-side error...see this guide for finding UI errors in your browser's DevTools: https://wiki.lyrasis.org/display/DSPACE/Troubleshoot+an+error#Troubleshootanerror-DSpace7.x(orabove)

My best guess is there's some sort of error occurring that's causing this behavior... either that, or something with your Administrator group or user account has gotten messed up.

Tim

---

From: 'Bill Tantzen' via DSpace Technical Support <dspac...@googlegroups.com>
Sent: Tuesday, February 8, 2022 1:00 PM
To: DSpace Technical Support <dspac...@googlegroups.com>
Subject: [dspace-tech] administrator actions in 7.2

 

--
All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/CADgrb7G2-TszXbDAHjeYo3bQbUQ2HQYOf_x%3DzGxRLKX6rdBHiQ%40mail.gmail.com.

[Bill Tantzen]

Sorry, forgot to copy the list.

In the apache logs, I see a number of GETs that look like:

/server/api/authz/authorizations/search/object?uri=https://udc-prd.lib.umn.edu/server/api/core/sites/0175ee52-5642-4302-89a1-99c444e5bd2c&feature=isCollectionAdmin&embed=feature

Is this what you are referring to?  With different features like isCommunityAdmin, etc.  Likely the stuff I am looking for.  All of them result in a code 200; no errors.

The same urls in the HAL browser result in:

{
  "_embedded": {
    "authorizations": [
      {
        "id": "e12c38cf-c5eb-4174-871c-3ce124d3889b_isCollectionAdmin_core.site_0175ee52-5642-4302-89a1-99c444e5bd2c",
        "type": "authorization",
        "_links": {
          "eperson": {
            "href": "https://udc-prd.lib.umn.edu/server/api/authz/authorizations/e12c38cf-c5eb-4174-871c-3ce124d3889b_isCollectionAdmin_core.site_0175ee52-5642-4302-89a1-99c444e5bd2c/eperson"
          },
          "feature": {
            "href": "https://udc-prd.lib.umn.edu/server/api/authz/authorizations/e12c38cf-c5eb-4174-871c-3ce124d3889b_isCollectionAdmin_core.site_0175ee52-5642-4302-89a1-99c444e5bd2c/feature"
          },
          "object": {
            "href": "https://udc-prd.lib.umn.edu/server/api/authz/authorizations/e12c38cf-c5eb-4174-871c-3ce124d3889b_isCollectionAdmin_core.site_0175ee52-5642-4302-89a1-99c444e5bd2c/object"
          },
          "self": {
            "href": "https://udc-prd.lib.umn.edu/server/api/authz/authorizations/e12c38cf-c5eb-4174-871c-3ce124d3889b_isCollectionAdmin_core.site_0175ee52-5642-4302-89a1-99c444e5bd2c"
          }
        },
        "_embedded": {
          "feature": {
            "id": "isCollectionAdmin",
            "description": "It can be used to verify if the current user is admin of any collection in the site",
            "type": "feature",
            "resourcetypes": [
              "core.site"
            ],
            "_links": {
              "self": {
                "href": "https://udc-prd.lib.umn.edu/server/api/authz/features/isCollectionAdmin"
              }
            }
          }
        }
      }
    ]
  },
  "_links": {
    "self": {
      "href": "https://udc-prd.lib.umn.edu/server/api/authz/authorizations/search/object?uri=https://udc-prd.lib.umn.edu/server/api/core/sites/0175ee52-5642-4302-89a1-99c444e5bd2c&feature=isCollectionAdmin"
    }
  },
  "page": {
    "size": 20,
    "totalElements": 1,
    "totalPages": 1,
    "number": 0
  }
}

Again, no errors

Does this look right?

Yep, I'm on 7.2 on both ends!!

~~Bill

On Tue, Feb 8, 2022 at 3:18 PM Bill Tantzen <tant...@umn.edu> wrote:

In the apache logs, I see a number of GETs that look like:

/server/api/authz/authorizations/search/object?uri=https://udc-prd.lib.umn.edu/server/api/core/sites/0175ee52-5642-4302-89a1-99c444e5bd2c&feature=isCollectionAdmin&embed=feature

Is this what you are referring to?  With different features like isCommunityAdmin, etc.  Likely the stuff I am looking for.  All of them result in a code 200; no errors.

The same urls in the HAL browser result in:

{
  "_links": {
    "self": {
      "href": "https://udc-prd.lib.umn.edu/server/api/authz/authorizations/search/object?uri=https://udc-prd.lib.umn.edu/server/api/core/sites/0175ee52-5642-4302-89a1-99c444e5bd2c&feature=isCollectionAdmin"
    }
  },
  "page": {
    "size": 20,
    "totalElements": 0,
    "totalPages": 0,
    "number": 0
  }
}

Again, no errors (but no results either)

Does this look right?

Yep, I'm on 7.2 on both ends!!

~~Bill

On Tue, Feb 8, 2022 at 3:11 PM Tim Donohue <tim.d...@lyrasis.org> wrote:

Good luck!

It's definitely not a configuration issue...this area of the code is not configurable.  It's either got to be an error causing it, or the data sent to the frontend from the backend is incorrect (make sure your backend is also running 7.2 obviously, as both frontend & backend should be on the same version.) 

Let us know what you find (on the list please, so that if others hit this, they can figure out what worked for you)

Tim

---

From: Bill Tantzen <tant...@umn.edu>
Sent: Tuesday, February 8, 2022 2:50 PM
To: Tim Donohue <tim.d...@lyrasis.org>
Subject: Re: [dspace-tech] administrator actions in 7.2

 

Oh no, I'm sure it's not a code issue;  I was thinking it was a new configuration setup.  I'll check the logs and see if there is any help there.  This worked fine in 7.0 and 7.1 (as well as the demo site), and I'm for sure a member of the Administrator group, so it's a little weird!

~~Bill

[Tim Donohue]

Hi Bill,

Yes, those GET requests are your UI attempting to check your permissions on the backend.

The one you sent has a "uri" equal to your "Site object", and a "feature=isCollectionAdmin".  That means it's attempting to check if you have Collection Admin rights on any​ Collection in the entire site.  Since it looks to be returning "totalElements: 0" that means the backend thinks you are not​ a Collection Admin on any Collection.  If you had this permission, that "totalElements" would be greater than zero.

Your result from the HAL browser is more accurate (returns "totalElements: 1" instead), and you should​ see the same result from the UI and HAL Browser if everything is setup properly.

So, this implies to me that something may be wrong with your setup.  My guess is that for some reason the backend doesn't "believe" you are authenticated...or it isn't trusting​ your frontend in some way. 

You should look very closely at the "Network" tab of your browser's DevTools when you login and especially after​ you have just logged in.  You shouldn't see any red, error responses from the backend...but my best guess is you likely will see something odd there.  Again, here's how to look for errors on the frontend: https://wiki.lyrasis.org/display/DSPACE/Troubleshoot+an+error#Troubleshootanerror-DSpace7.x(orabove)

I'd venture to guess you might be hitting an installation/upgrade error, it might even be one of these common installation issues: https://wiki.lyrasis.org/display/DSDOC7x/Installing+DSpace#InstallingDSpace-CommonInstallationIssues  (Usually these are caused by a misconfiguration between the frontend & backend)

If none of that helps...check all your backend logs very closely and look for ERROR messages there.  Something seems "off", and it sounds to me like your Backend is either not trusting the frontend, or your Backend is silently erroring out every time you try to login.

Tim

---

From: 'Bill Tantzen' via DSpace Technical Support <dspac...@googlegroups.com>

Sent: Tuesday, February 8, 2022 3:31 PM

To: DSpace Technical Support <dspac...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/CADgrb7E0NvgjFiBxNiHVHJf%2B7Zbx6MKCL37pGqhbRiZk9AfEBw%40mail.gmail.com.

[Bill Tantzen]

All,

I believe I have figured out what is going on.  Yes, it seems that I am running the old version of the frontend.

This happens because I have both versions (dspace-angular-dspace-7.1 and dspace-angular-dspace-7.2) in the same directory.  When I execute 

    pm2 start dspace-angular.json

the old version is served up.  Yes, I have updated my dspace-angular.json file to point to the correct directory.  In fact, when I remove the old version, pm2 will serve an error page instead:

<pre>Error: ENOENT: no such file or directory, stat &#39;/dspace/projects/dspace-angular-dspace-7.1/dist/browser/index.html&#39;</pre>

pm2 simply refuses to start the correct application.  This is the latest version (v4.5.6 by the way).

I realize this is NOT a DSpace problem, but I'm hoping that somebody else has run into this problem and solved it.  I have scoured the web trying to figure this out with no luck so far.

Any pm2 experts on the list?

~~Bill

[Tim Donohue]

Bill,

Something simple...have you double checked the "cwd" directory in your dspace-angular.json​ configuration for PM2?  That's the directory where PM2 should run the "yarn run serve:ssr".  So, if that "cwd" directory is your 7.1 root folder, it'll always run 7.1.  If it's your 7.2 root folder, it should always run 7.2.

Essentially, I'd first look more closely at the JSON config you are passing to PM2.  It sounds like PM2 is either running yarn from the wrong folder, or somehow getting confused by your config.

Tim

---

From: 'Bill Tantzen' via DSpace Technical Support <dspac...@googlegroups.com>

Sent: Wednesday, February 9, 2022 8:03 AM
To: Tim Donohue <tim.d...@lyrasis.org>
Cc: DSpace Technical Support <dspac...@googlegroups.com>

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/CADgrb7G%3D4q6XHxPHtjBHvMO_QrDN1WP0mJWx6m8ucazByRhjkQ%40mail.gmail.com.

[Bill Tantzen]

Yes, the start file is correct -- I have checked and double checked!

[Tim Donohue]

Hi Bill,

Ok, just double checking.

In that case, my best guess is something is "cached" in PM2 itself.

Make sure that all the PM2 processes related to DSpace are fully stopped. Check your running processes.  You also could try "pm2 stop dspace-angular.json".

If that also doesn't work, try deleting​ your app config (in PM2), and starting again.  So, something like:

pm2 delete dspace-angular.json

pm2 start dspace-angular.json

(This obviously won't delete your dspace-angular app entirely, it just deletes your previous PM2 configuration for dspace-angular, in case that's getting in the way)

That hint came via Google, where I stumbled on what looks to be a similar discussion in this old PM2 issue ticket: https://github.com/Unitech/pm2/issues/96#issuecomment-817920882

If this works for you (or you find a different fix), let us know...we may need to copy this hint into our Upgrade Guide in case others run across this same issue.

Tim

---

From: Bill Tantzen <tant...@umn.edu>
Sent: Wednesday, February 9, 2022 8:54 AM

[Bill Tantzen]

OK, problem solved, and it's not really a pm2 issue.

It seems there was a stale node process holding onto port 4000 (even though netstat did not reveal it).  I manually killed that process, restarted the server with pm2, and voila!  This was not really apparent in checking the pm2 logs, which actually indicated everything was fine and executing from the correct project.

Just a guess, but maybe in the process of upgrading the previous version was not stopped properly by pm2?  Hard to say now. But everything is working fine now.

~~Bill

[Jayachristrayar S]

am facing same issue on dspace cris 8 can you help me