Empathy List Archives

NK

Nathan Kerr

Wed, Jun 22, 2016 5:48 PM

Hi All,

Recent strange occurrence that I can't explain, and would love some
guidance on a possible fix for:

Previously our development instance of CSpace had 2 location authorities:

'Local Storage Locations' (956ad75f-7882-4bbe-b6c8)
'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820)

We are only using Local Storage Locations. Yesterday the record for this
Authority disappeared, this is causing some serious problems in the ui. I
can still see all of the terms in the authority via postgres and the api,
but

localhost/cspace-services/locationauthorities

only shows 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820)

All of the terms still have the csid (956ad75f-7882-4bbe-b6c8) as their
inauthority value. Is there a way to simply recreate the Authority and
specify the csid? I (probably in ignorance) assume that would fix the
problem. Any guidance is helpful.

Thanks,
Nathan

--
Nathan Kerr
Digital Resource Program Manager
Oakland Museum of California
1000 Oak St
Oakland CA, 94607
510-318-8494
nkerr@museumca.org

Hi All, Recent strange occurrence that I can't explain, and would love some guidance on a possible fix for: Previously our development instance of CSpace had 2 location authorities: 'Local Storage Locations' (956ad75f-7882-4bbe-b6c8) 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820) We are only using Local Storage Locations. Yesterday the record for this Authority disappeared, this is causing some serious problems in the ui. I can still see all of the terms in the authority via postgres and the api, but localhost/cspace-services/locationauthorities only shows 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820) All of the terms still have the csid (956ad75f-7882-4bbe-b6c8) as their inauthority value. Is there a way to simply recreate the Authority and specify the csid? I (probably in ignorance) assume that would fix the problem. Any guidance is helpful. Thanks, Nathan -- *Nathan Kerr* Digital Resource Program Manager Oakland Museum of California 1000 Oak St Oakland CA, 94607 510-318-8494 nkerr@museumca.org

RL

Ray Lee

Thu, Jun 23, 2016 4:08 AM

Well that's scary. Do you keep the tomcat localhost_access logs around? I
wonder if someone meant to delete a location item through the REST API, but
forgot the /items/<csid> part of the URL, and deleted the authority
instance instead. If that's the case, you'd see the DELETE request in the
log. The only other way to delete it would be an SQL query. Or some kind of
bug?

To fix: If you visit the /authorities/initialise URL, it should recreate
the Local Storage Locations authority. The newly created instance won't
have the same csid, but you can do an SQL update to the appropriate row in
the hierarchy table to change it to the csid you want. Then restart tomcat,
and it should work. You'll probably want to back up the database before
doing any of that.

Ray

On Wed, Jun 22, 2016 at 10:48 AM, Nathan Kerr nkerr@museumca.org wrote:

Hi All,

Recent strange occurrence that I can't explain, and would love some
guidance on a possible fix for:

Previously our development instance of CSpace had 2 location authorities:

'Local Storage Locations' (956ad75f-7882-4bbe-b6c8)
'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820)

We are only using Local Storage Locations. Yesterday the record for this
Authority disappeared, this is causing some serious problems in the ui. I
can still see all of the terms in the authority via postgres and the api,
but

localhost/cspace-services/locationauthorities

only shows 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820)

All of the terms still have the csid (956ad75f-7882-4bbe-b6c8) as their
inauthority value. Is there a way to simply recreate the Authority and
specify the csid? I (probably in ignorance) assume that would fix the
problem. Any guidance is helpful.

Thanks,
Nathan

--
Nathan Kerr
Digital Resource Program Manager
Oakland Museum of California
1000 Oak St
Oakland CA, 94607
510-318-8494
nkerr@museumca.org

Talk mailing list
Talk@lists.collectionspace.org

http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

Well that's scary. Do you keep the tomcat localhost_access logs around? I wonder if someone meant to delete a location item through the REST API, but forgot the /items/<csid> part of the URL, and deleted the authority instance instead. If that's the case, you'd see the DELETE request in the log. The only other way to delete it would be an SQL query. Or some kind of bug? To fix: If you visit the /authorities/initialise URL, it should recreate the Local Storage Locations authority. The newly created instance won't have the same csid, but you can do an SQL update to the appropriate row in the hierarchy table to change it to the csid you want. Then restart tomcat, and it should work. You'll probably want to back up the database before doing any of that. Ray On Wed, Jun 22, 2016 at 10:48 AM, Nathan Kerr <nkerr@museumca.org> wrote: > Hi All, > > Recent strange occurrence that I can't explain, and would love some > guidance on a possible fix for: > > Previously our development instance of CSpace had 2 location authorities: > > 'Local Storage Locations' (956ad75f-7882-4bbe-b6c8) > 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820) > > We are only using Local Storage Locations. Yesterday the record for this > Authority disappeared, this is causing some serious problems in the ui. I > can still see all of the terms in the authority via postgres and the api, > but > > localhost/cspace-services/locationauthorities > > only shows 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820) > > All of the terms still have the csid (956ad75f-7882-4bbe-b6c8) as their > inauthority value. Is there a way to simply recreate the Authority and > specify the csid? I (probably in ignorance) assume that would fix the > problem. Any guidance is helpful. > > Thanks, > Nathan > > -- > *Nathan Kerr* > Digital Resource Program Manager > Oakland Museum of California > 1000 Oak St > Oakland CA, 94607 > 510-318-8494 > nkerr@museumca.org > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

NK

Nathan Kerr

Thu, Jun 23, 2016 6:48 PM

Thanks Ray!

Scary indeed. This is really helpful.

On Wed, Jun 22, 2016 at 9:08 PM, Ray Lee rhlee@berkeley.edu wrote:

Well that's scary. Do you keep the tomcat localhost_access logs around? I
wonder if someone meant to delete a location item through the REST API, but
forgot the /items/<csid> part of the URL, and deleted the authority
instance instead. If that's the case, you'd see the DELETE request in the
log. The only other way to delete it would be an SQL query. Or some kind of
bug?

To fix: If you visit the /authorities/initialise URL, it should recreate
the Local Storage Locations authority. The newly created instance won't
have the same csid, but you can do an SQL update to the appropriate row in
the hierarchy table to change it to the csid you want. Then restart tomcat,
and it should work. You'll probably want to back up the database before
doing any of that.

Ray

On Wed, Jun 22, 2016 at 10:48 AM, Nathan Kerr nkerr@museumca.org wrote:

Hi All,

Recent strange occurrence that I can't explain, and would love some
guidance on a possible fix for:

Previously our development instance of CSpace had 2 location authorities:

'Local Storage Locations' (956ad75f-7882-4bbe-b6c8)
'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820)

We are only using Local Storage Locations. Yesterday the record for this
Authority disappeared, this is causing some serious problems in the ui. I
can still see all of the terms in the authority via postgres and the api,
but

localhost/cspace-services/locationauthorities

only shows 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820)

All of the terms still have the csid (956ad75f-7882-4bbe-b6c8) as their
inauthority value. Is there a way to simply recreate the Authority and
specify the csid? I (probably in ignorance) assume that would fix the
problem. Any guidance is helpful.

Thanks,
Nathan

--
Nathan Kerr
Digital Resource Program Manager
Oakland Museum of California
1000 Oak St
Oakland CA, 94607
510-318-8494
nkerr@museumca.org

Talk mailing list
Talk@lists.collectionspace.org

http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

--
Nathan Kerr
Digital Resource Program Manager
Oakland Museum of California
1000 Oak St
Oakland CA, 94607
510-318-8494
nkerr@museumca.org

Thanks Ray! Scary indeed. This is really helpful. On Wed, Jun 22, 2016 at 9:08 PM, Ray Lee <rhlee@berkeley.edu> wrote: > Well that's scary. Do you keep the tomcat localhost_access logs around? I > wonder if someone meant to delete a location item through the REST API, but > forgot the /items/<csid> part of the URL, and deleted the authority > instance instead. If that's the case, you'd see the DELETE request in the > log. The only other way to delete it would be an SQL query. Or some kind of > bug? > > To fix: If you visit the /authorities/initialise URL, it should recreate > the Local Storage Locations authority. The newly created instance won't > have the same csid, but you can do an SQL update to the appropriate row in > the hierarchy table to change it to the csid you want. Then restart tomcat, > and it should work. You'll probably want to back up the database before > doing any of that. > > Ray > > > > > On Wed, Jun 22, 2016 at 10:48 AM, Nathan Kerr <nkerr@museumca.org> wrote: > >> Hi All, >> >> Recent strange occurrence that I can't explain, and would love some >> guidance on a possible fix for: >> >> Previously our development instance of CSpace had 2 location authorities: >> >> 'Local Storage Locations' (956ad75f-7882-4bbe-b6c8) >> 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820) >> >> We are only using Local Storage Locations. Yesterday the record for this >> Authority disappeared, this is causing some serious problems in the ui. I >> can still see all of the terms in the authority via postgres and the api, >> but >> >> localhost/cspace-services/locationauthorities >> >> only shows 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820) >> >> All of the terms still have the csid (956ad75f-7882-4bbe-b6c8) as their >> inauthority value. Is there a way to simply recreate the Authority and >> specify the csid? I (probably in ignorance) assume that would fix the >> problem. Any guidance is helpful. >> >> Thanks, >> Nathan >> >> -- >> *Nathan Kerr* >> Digital Resource Program Manager >> Oakland Museum of California >> 1000 Oak St >> Oakland CA, 94607 >> 510-318-8494 >> nkerr@museumca.org >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> > -- *Nathan Kerr* Digital Resource Program Manager Oakland Museum of California 1000 Oak St Oakland CA, 94607 510-318-8494 nkerr@museumca.org

RM

Richard Millet

Thu, Jun 23, 2016 7:01 PM

Nathan,

As Ray mentioned, please take a look at (or send us) the log files dated close to when you first noticed this problem. If it turns out to be a bug, we really need to find and fix this quickly. Also, what version of CollectionSpace are you using?

Thanks,

Richard

From: Talk talk-bounces@lists.collectionspace.org on behalf of Nathan Kerr nkerr@museumca.org
Sent: Thursday, June 23, 2016 11:48 AM
To: Ray Lee
Cc: CollectionSpace Talk List
Subject: Re: [Talk] Recreating Storage Loaction Authority

Thanks Ray!

Scary indeed. This is really helpful.

On Wed, Jun 22, 2016 at 9:08 PM, Ray Lee <rhlee@berkeley.edu mailto:rhlee@berkeley.edu> wrote:
Well that's scary. Do you keep the tomcat localhost_access logs around? I wonder if someone meant to delete a location item through the REST API, but forgot the /items/<csid> part of the URL, and deleted the authority instance instead. If that's the case, you'd see the DELETE request in the log. The only other way to delete it would be an SQL query. Or some kind of bug?

To fix: If you visit the /authorities/initialise URL, it should recreate the Local Storage Locations authority. The newly created instance won't have the same csid, but you can do an SQL update to the appropriate row in the hierarchy table to change it to the csid you want. Then restart tomcat, and it should work. You'll probably want to back up the database before doing any of that.

Ray

On Wed, Jun 22, 2016 at 10:48 AM, Nathan Kerr <nkerr@museumca.org mailto:nkerr@museumca.org> wrote:
Hi All,

Recent strange occurrence that I can't explain, and would love some guidance on a possible fix for:

Previously our development instance of CSpace had 2 location authorities:

'Local Storage Locations' (956ad75f-7882-4bbe-b6c8)
'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820)

We are only using Local Storage Locations. Yesterday the record for this Authority disappeared, this is causing some serious problems in the ui. I can still see all of the terms in the authority via postgres and the api, but

localhost/cspace-services/locationauthorities

only shows 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820)

All of the terms still have the csid (956ad75f-7882-4bbe-b6c8) as their inauthority value. Is there a way to simply recreate the Authority and specify the csid? I (probably in ignorance) assume that would fix the problem. Any guidance is helpful.

Thanks,
Nathan

--
Nathan Kerr
Digital Resource Program Manager
Oakland Museum of California
1000 Oak St
Oakland CA, 94607
510-318-8494tel:510-318-8494
nkerr@museumca.org mailto:nkerr@museumca.org

Talk mailing list
Talk@lists.collectionspace.org mailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

--
Nathan Kerr
Digital Resource Program Manager
Oakland Museum of California
1000 Oak St
Oakland CA, 94607
510-318-8494
nkerr@museumca.org mailto:nkerr@museumca.org

Nathan, As Ray mentioned, please take a look at (or send us) the log files dated close to when you first noticed this problem. If it turns out to be a bug, we really need to find and fix this quickly. Also, what version of CollectionSpace are you using? Thanks, Richard ________________________________________ From: Talk <talk-bounces@lists.collectionspace.org> on behalf of Nathan Kerr <nkerr@museumca.org> Sent: Thursday, June 23, 2016 11:48 AM To: Ray Lee Cc: CollectionSpace Talk List Subject: Re: [Talk] Recreating Storage Loaction Authority Thanks Ray! Scary indeed. This is really helpful. On Wed, Jun 22, 2016 at 9:08 PM, Ray Lee <rhlee@berkeley.edu<mailto:rhlee@berkeley.edu>> wrote: Well that's scary. Do you keep the tomcat localhost_access logs around? I wonder if someone meant to delete a location item through the REST API, but forgot the /items/<csid> part of the URL, and deleted the authority instance instead. If that's the case, you'd see the DELETE request in the log. The only other way to delete it would be an SQL query. Or some kind of bug? To fix: If you visit the /authorities/initialise URL, it should recreate the Local Storage Locations authority. The newly created instance won't have the same csid, but you can do an SQL update to the appropriate row in the hierarchy table to change it to the csid you want. Then restart tomcat, and it should work. You'll probably want to back up the database before doing any of that. Ray On Wed, Jun 22, 2016 at 10:48 AM, Nathan Kerr <nkerr@museumca.org<mailto:nkerr@museumca.org>> wrote: Hi All, Recent strange occurrence that I can't explain, and would love some guidance on a possible fix for: Previously our development instance of CSpace had 2 location authorities: 'Local Storage Locations' (956ad75f-7882-4bbe-b6c8) 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820) We are only using Local Storage Locations. Yesterday the record for this Authority disappeared, this is causing some serious problems in the ui. I can still see all of the terms in the authority via postgres and the api, but localhost/cspace-services/locationauthorities only shows 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820) All of the terms still have the csid (956ad75f-7882-4bbe-b6c8) as their inauthority value. Is there a way to simply recreate the Authority and specify the csid? I (probably in ignorance) assume that would fix the problem. Any guidance is helpful. Thanks, Nathan -- Nathan Kerr Digital Resource Program Manager Oakland Museum of California 1000 Oak St Oakland CA, 94607 510-318-8494<tel:510-318-8494> nkerr@museumca.org<mailto:nkerr@museumca.org> _______________________________________________ Talk mailing list Talk@lists.collectionspace.org<mailto:Talk@lists.collectionspace.org> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org -- Nathan Kerr Digital Resource Program Manager Oakland Museum of California 1000 Oak St Oakland CA, 94607 510-318-8494 nkerr@museumca.org<mailto:nkerr@museumca.org>

NK

Nathan Kerr

Thu, Jun 23, 2016 7:44 PM

Will do Richard.

We're using 4.3.

Thanks,
Nathan

On Thu, Jun 23, 2016 at 12:01 PM, Richard Millet <richard.millet@lyrasis.org

wrote:

Nathan,

As Ray mentioned, please take a look at (or send us) the log files dated
close to when you first noticed this problem. If it turns out to be a bug,
we really need to find and fix this quickly. Also, what version of
CollectionSpace are you using?

Thanks,

Richard

From: Talk talk-bounces@lists.collectionspace.org on behalf of Nathan
Kerr nkerr@museumca.org
Sent: Thursday, June 23, 2016 11:48 AM
To: Ray Lee
Cc: CollectionSpace Talk List
Subject: Re: [Talk] Recreating Storage Loaction Authority

Thanks Ray!

Scary indeed. This is really helpful.

On Wed, Jun 22, 2016 at 9:08 PM, Ray Lee <rhlee@berkeley.edu<mailto:
rhlee@berkeley.edu>> wrote:
Well that's scary. Do you keep the tomcat localhost_access logs around? I
wonder if someone meant to delete a location item through the REST API, but
forgot the /items/<csid> part of the URL, and deleted the authority
instance instead. If that's the case, you'd see the DELETE request in the
log. The only other way to delete it would be an SQL query. Or some kind of
bug?

To fix: If you visit the /authorities/initialise URL, it should recreate
the Local Storage Locations authority. The newly created instance won't
have the same csid, but you can do an SQL update to the appropriate row in
the hierarchy table to change it to the csid you want. Then restart tomcat,
and it should work. You'll probably want to back up the database before
doing any of that.

Ray

On Wed, Jun 22, 2016 at 10:48 AM, Nathan Kerr <nkerr@museumca.org<mailto:
nkerr@museumca.org>> wrote:
Hi All,

Recent strange occurrence that I can't explain, and would love some
guidance on a possible fix for:

Previously our development instance of CSpace had 2 location authorities:

'Local Storage Locations' (956ad75f-7882-4bbe-b6c8)
'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820)

We are only using Local Storage Locations. Yesterday the record for this
Authority disappeared, this is causing some serious problems in the ui. I
can still see all of the terms in the authority via postgres and the api,
but

localhost/cspace-services/locationauthorities

only shows 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820)

All of the terms still have the csid (956ad75f-7882-4bbe-b6c8) as their
inauthority value. Is there a way to simply recreate the Authority and
specify the csid? I (probably in ignorance) assume that would fix the
problem. Any guidance is helpful.

Thanks,
Nathan

--
Nathan Kerr
Digital Resource Program Manager
Oakland Museum of California
1000 Oak St
Oakland CA, 94607
510-318-8494tel:510-318-8494
nkerr@museumca.org mailto:nkerr@museumca.org

Talk mailing list
Talk@lists.collectionspace.org mailto:Talk@lists.collectionspace.org

http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org

--
Nathan Kerr
Digital Resource Program Manager
Oakland Museum of California
1000 Oak St
Oakland CA, 94607
510-318-8494
nkerr@museumca.org mailto:nkerr@museumca.org

--
Nathan Kerr
Digital Resource Program Manager
Oakland Museum of California
1000 Oak St
Oakland CA, 94607
510-318-8494
nkerr@museumca.org

Will do Richard. We're using 4.3. Thanks, Nathan On Thu, Jun 23, 2016 at 12:01 PM, Richard Millet <richard.millet@lyrasis.org > wrote: > Nathan, > > As Ray mentioned, please take a look at (or send us) the log files dated > close to when you first noticed this problem. If it turns out to be a bug, > we really need to find and fix this quickly. Also, what version of > CollectionSpace are you using? > > Thanks, > > Richard > > ________________________________________ > From: Talk <talk-bounces@lists.collectionspace.org> on behalf of Nathan > Kerr <nkerr@museumca.org> > Sent: Thursday, June 23, 2016 11:48 AM > To: Ray Lee > Cc: CollectionSpace Talk List > Subject: Re: [Talk] Recreating Storage Loaction Authority > > Thanks Ray! > > Scary indeed. This is really helpful. > > On Wed, Jun 22, 2016 at 9:08 PM, Ray Lee <rhlee@berkeley.edu<mailto: > rhlee@berkeley.edu>> wrote: > Well that's scary. Do you keep the tomcat localhost_access logs around? I > wonder if someone meant to delete a location item through the REST API, but > forgot the /items/<csid> part of the URL, and deleted the authority > instance instead. If that's the case, you'd see the DELETE request in the > log. The only other way to delete it would be an SQL query. Or some kind of > bug? > > To fix: If you visit the /authorities/initialise URL, it should recreate > the Local Storage Locations authority. The newly created instance won't > have the same csid, but you can do an SQL update to the appropriate row in > the hierarchy table to change it to the csid you want. Then restart tomcat, > and it should work. You'll probably want to back up the database before > doing any of that. > > Ray > > > > > On Wed, Jun 22, 2016 at 10:48 AM, Nathan Kerr <nkerr@museumca.org<mailto: > nkerr@museumca.org>> wrote: > Hi All, > > Recent strange occurrence that I can't explain, and would love some > guidance on a possible fix for: > > Previously our development instance of CSpace had 2 location authorities: > > 'Local Storage Locations' (956ad75f-7882-4bbe-b6c8) > 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820) > > We are only using Local Storage Locations. Yesterday the record for this > Authority disappeared, this is causing some serious problems in the ui. I > can still see all of the terms in the authority via postgres and the api, > but > > localhost/cspace-services/locationauthorities > > only shows 'Offsite Storage Locations' (7c60b4db-ce2f-4220-9820) > > All of the terms still have the csid (956ad75f-7882-4bbe-b6c8) as their > inauthority value. Is there a way to simply recreate the Authority and > specify the csid? I (probably in ignorance) assume that would fix the > problem. Any guidance is helpful. > > Thanks, > Nathan > > -- > Nathan Kerr > Digital Resource Program Manager > Oakland Museum of California > 1000 Oak St > Oakland CA, 94607 > 510-318-8494<tel:510-318-8494> > nkerr@museumca.org<mailto:nkerr@museumca.org> > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org<mailto:Talk@lists.collectionspace.org> > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > > > > > > -- > Nathan Kerr > Digital Resource Program Manager > Oakland Museum of California > 1000 Oak St > Oakland CA, 94607 > 510-318-8494 > nkerr@museumca.org<mailto:nkerr@museumca.org> > > -- *Nathan Kerr* Digital Resource Program Manager Oakland Museum of California 1000 Oak St Oakland CA, 94607 510-318-8494 nkerr@museumca.org

talk@lists.collectionspace.org

Recreating Storage Loaction Authority