[dspace-tech] Re: Search Issues in DSpace 7.x
Hello, run this command from the console curl http://localhost:8983/solr/admin/cores ... What do you see? On Thursday, February 10, 2022 at 12:40:02 AM UTC+3 sto...@hope.ac.uk wrote: > Hello All, > > I upgraded our 6.3 site to 7.1.1, after some configuration issues I did > manage to get it up and running but kept on hitting this issue and issue > where it wouldn't bring back any items. I checked the log and saw this : > > Caused by: org.dspace.browse.BrowseException: > org.dspace.discovery.SearchServiceException: Error from server at > http://localhost:8983/solr/search: can not sort on multivalued field: > bi_sort_1_sort of type: text_general > > I did try and upgrade to 7.2 and again after some configuration issues I > did manage to get it running but have exacltly the same issue. > > Does anyone have any idea how to fix this ? > > Thanks > > Jeff > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/c9dcd687-ece3-4260-8fd7-613c94d993e6n%40googlegroups.com.
[dspace-tech] Search Issues in DSpace 7.x
Hello All, I upgraded our 6.3 site to 7.1.1, after some configuration issues I did manage to get it up and running but kept on hitting this issue and issue where it wouldn't bring back any items. I checked the log and saw this : Caused by: org.dspace.browse.BrowseException: org.dspace.discovery.SearchServiceException: Error from server at http://localhost:8983/solr/search: can not sort on multivalued field: bi_sort_1_sort of type: text_general I did try and upgrade to 7.2 and again after some configuration issues I did manage to get it running but have exacltly the same issue. Does anyone have any idea how to fix this ? Thanks Jeff -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/a13aad79-ce36-4dff-b09f-cadac485f95bn%40googlegroups.com.
[dspace-tech] How to enable IIIF for item in 7.2?
How is an items bitstreams enabled for iiif in 7.2? If I attempt to edit the item metadata, and add the field "dspace.iiif.enabled", it is red lined and I am told to enter a valid value. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/f0772285-a4aa-4981-bbcc-b177a4cdebb5n%40googlegroups.com.
[dspace-tech] Re: How to migrate your UI Configurations to YAML ?
WARNING - My method of using the relative paths to the earlier DS 7.1 directory did run under the yarn env:yaml script, but it did not produce a useful config.prod.yml file. Angular insisted on listening at localhost:8080, rather than localhost:4000. I don't know why this didn't work, but Mohammad's suggestion of editing the config.example.yml to define my URLs and ports worked much better and easier. On Wednesday, February 9, 2022 at 2:15:00 AM UTC-5 alo...@gmail.com wrote: > On Wednesday, February 9, 2022 at 2:47:08 AM UTC+3 Chris Clawson wrote: > >> Everything seemed to finish well, although a full system reboot failed >> to start angular as a service. I guess this is my last barrier to a >> functional upgrade, but it is the stuff of a new thread if I need help. >> > > You need to replace the ExecStart line in the service startup script as > you see below and you also need to change the WorkingDirectory path to > reflect the new path if it's changed. > vi /lib/systemd/system/dspace-angular.service > ExecStart=/usr/bin/node dist/server/main > WorkingDirectory=/opt/dspace-angular > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/90d07c77-22cb-4df5-8f5a-a25756a19d34n%40googlegroups.com.
Re: [dspace-tech] administrator actions in 7.2
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 On Wed, Feb 9, 2022 at 9:18 AM Tim Donohue wrote: > 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 > *Sent:* Wednesday, February 9, 2022 8:54 AM > *To:* Tim Donohue > *Cc:* DSpace Technical Support > *Subject:* Re: [dspace-tech] administrator actions in 7.2 > > Yes, the start file is correct -- I have checked and double checked! > > On Wed, Feb 9, 2022 at 8:46 AM Tim Donohue > wrote: > > 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 < > dspace-tech@googlegroups.com> > *Sent:* Wednesday, February 9, 2022 8:03 AM > *To:* Tim Donohue > *Cc:* DSpace Technical Support > *Subject:* Re: [dspace-tech] administrator actions in 7.2 > > 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: > > Error: ENOENT: no such file or directory, stat > /dspace/projects/dspace-angular-dspace-7.1/dist/browser/index.html > > 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 > > > > On Tue, Feb 8, 2022 at 4:24 PM Tim Donohue > wrote: > > 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
Re: [dspace-tech] administrator actions in 7.2
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 Sent: Wednesday, February 9, 2022 8:54 AM To: Tim Donohue Cc: DSpace Technical Support Subject: Re: [dspace-tech] administrator actions in 7.2 Yes, the start file is correct -- I have checked and double checked! On Wed, Feb 9, 2022 at 8:46 AM Tim Donohue mailto:tim.dono...@lyrasis.org>> wrote: 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 mailto:dspace-tech@googlegroups.com>> Sent: Wednesday, February 9, 2022 8:03 AM To: Tim Donohue mailto:tim.dono...@lyrasis.org>> Cc: DSpace Technical Support mailto:dspace-tech@googlegroups.com>> Subject: Re: [dspace-tech] administrator actions in 7.2 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: Error: ENOENT: no such file or directory, stat /dspace/projects/dspace-angular-dspace-7.1/dist/browser/index.html 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 On Tue, Feb 8, 2022 at 4:24 PM Tim Donohue mailto:tim.dono...@lyrasis.org>> wrote: 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
Re: [dspace-tech] administrator actions in 7.2
Yes, the start file is correct -- I have checked and double checked!
On Wed, Feb 9, 2022 at 8:46 AM Tim Donohue wrote:
> 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 <
> dspace-tech@googlegroups.com>
> *Sent:* Wednesday, February 9, 2022 8:03 AM
> *To:* Tim Donohue
> *Cc:* DSpace Technical Support
> *Subject:* Re: [dspace-tech] administrator actions in 7.2
>
> 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:
>
> Error: ENOENT: no such file or directory, stat
> /dspace/projects/dspace-angular-dspace-7.1/dist/browser/index.html
>
> 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
>
>
>
> On Tue, Feb 8, 2022 at 4:24 PM Tim Donohue
> wrote:
>
> 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 <
> dspace-tech@googlegroups.com>
> *Sent:* Tuesday, February 8, 2022 3:31 PM
> *To:* DSpace Technical Support
> *Subject:* Re: [dspace-tech] administrator actions in 7.2
>
> 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=isCollectionAdmin=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": {
>
Re: [dspace-tech] administrator actions in 7.2
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
Sent: Wednesday, February 9, 2022 8:03 AM
To: Tim Donohue
Cc: DSpace Technical Support
Subject: Re: [dspace-tech] administrator actions in 7.2
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:
Error: ENOENT: no such file or directory, stat
/dspace/projects/dspace-angular-dspace-7.1/dist/browser/index.html
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
On Tue, Feb 8, 2022 at 4:24 PM Tim Donohue
mailto:tim.dono...@lyrasis.org>> wrote:
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
mailto:dspace-tech@googlegroups.com>>
Sent: Tuesday, February 8, 2022 3:31 PM
To: DSpace Technical Support
mailto:dspace-tech@googlegroups.com>>
Subject: Re: [dspace-tech] administrator actions in 7.2
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=isCollectionAdmin=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":
Re: [dspace-tech] Re: DSpace 6.3 - Time zone issue
On Tue, Feb 08, 2022 at 10:12:05AM -0800, 'Tim Donohue' via DSpace Technical Support wrote: > Hi Juan, > > At the database level, DSpace will only save dates in UTC format (this is > true for any version of DSpace, including 7.x). So, all dates are > formatted to UTC before they are saved in the database as metadata. This is > necessary to make things like time-base access restrictions (e.g. > embargoes) and other date comparisons easier in the codebase. > > It's currently not possible to change this behavior (at least not easily, > and it could have side effects for embargoes and similar if you change it). > > That said, you might be able to customize how those dates are displayed in > the User Interface, if you want them to appear in local timezone (you'd > just need to translate them back form UTC to local time). But, just be > aware that if you change/save a date in the User Interface, it'll always be > converted to UTC before it's saved to the database. > > Tim > > On Tuesday, February 8, 2022 at 7:35:14 AM UTC-6 juanlop...@gmail.com wrote: > > > Hi all! > > > > I'm seeing an odd behaviour on my Dspace 6.3. Whenever there is a new item > > submission, the dc.date.accessioned and dc.date.available are saved with > > UTC time but it should be with the local time that my server and database > > have: > > > > [image: imagen_2022-02-08_083220.png] > > > > Do you guys know if DSpace uses only UTC time to create this metadata? > > > > Is there a way to make DSpace use America/Bogota timezone? I would propose that as a best practice: o always store time in UTC o always present and accept time in the zone that the user expects. (Bearing in mind that a more technically-minded user may expect UTC!) We should think about whether DSpace is consistent and most usable in its handling of time. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/YgPTZHb7iqWq4VwR%40IUPUI.Edu. signature.asc Description: PGP signature
Re: [dspace-tech] administrator actions in 7.2
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:
Error: ENOENT: no such file or directory, stat
/dspace/projects/dspace-angular-dspace-7.1/dist/browser/index.html
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
On Tue, Feb 8, 2022 at 4:24 PM Tim Donohue wrote:
> 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 <
> dspace-tech@googlegroups.com>
> *Sent:* Tuesday, February 8, 2022 3:31 PM
> *To:* DSpace Technical Support
> *Subject:* Re: [dspace-tech] administrator actions in 7.2
>
> 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=isCollectionAdmin=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": {
>
