ScholarSphere deposit by admin acting as user not showing in RMD

[anaelizabethenriquez]

Earlier today, I used RMD to make a ScholarSphere deposit on behalf of user jxr67 (while logged in as an admin, acting as jxr67). It seemed successful. I got a confirmation message on screen in RMD, and I see the deposit in ScholarSphere. However, I don't see any indication in RMD now that this has happened. The publication has a question mark for the OA Status icon, and there aren't any OA Locations.

This publication was in a duplicate group, but I merged it before I uploaded to ScholarSphere. Nicole deleted the duplicate group.

[ajkiessl]

We did fix this issue, but it's bundled up with the changes for the next release, so it won't be released until after Thanksgiving. With the emails going out next week, I'm assuming you'll have to do more proxy SS submitting? If that's the case, we can work on getting a patch out before Thanksgiving.

[awead]

@ajkiessl We did? I do remember fixing the issue with selecting and ordering publications for display on the user's public profile, but this seems different. By depositing into Scholarsphere it should make that publication open access. If the fix does need to be deployed to production, we can cherry-pick it out of main and into a hotfix branch and deploy that.

[awead]

Here's the ticket for the issue I thought you were referring to: https://github.com/psu-stewardship/researcher-metadata/issues/322

[anaelizabethenriquez]

OK. I do anticipate doing quite a few of these next week, so it would be nice to have this in place before the emails go out. But I could also add links manually if needed. Will I need to do that for this one, or is it something the system would pick up when the fix goes out?

[ajkiessl]

@anaelizabethenriquez If the submission to Scholarsphere is successful, then it should add a Scholarsphere OAL and the publication should now appear as open access. For this one, the link will have to be added manually. Although, if there's a doi, there's a chance it gets picked up on the next scholarsphere import.

@awead You're right that's the ticket I was thinking of. I just tried this out on staging, and thought it was working, but I didn't quite do it right. Let me double check to see if the changes we made fixes this issue. If not then there's something else going on.

[awead]

When I tested this out via Dan's account, the publication did go from "?" to the "unlocked" icon, so there could be something else going on here. In any case, if there's a change that needs to happen, we can always hotfix that and get it out before the emails start arriving.

[anaelizabethenriquez]

I've added the link manually for this publication.

[ajkiessl]

It seems to be working in staging. I just submitted a document as Nicole, and it added the scholarsphere OAL.

[EricDurante]

@anaelizabethenriquez When you say, "I don't see any indication in RMD now that this has happened", I just want to clarify something: RMD did at least properly record that the deposit into ScholarSphere occurred, correct? (I assume that it's this record in RMD: https://metadata.libraries.psu.edu/admin/scholarsphere_work_deposit/232). So, if I understand, what you're saying is that RMD just wasn't properly indicating that this publication was open access - is that right?

[anaelizabethenriquez]

Yes, that's correct @EricDurante. I hadn't seen the deposit record yet when I wrote that.

As I mentioned on Slack, I tried this again in production this morning with Publication 285738, and it recorded the URL correctly. I'm wondering if the problem in this ticket has to do with it being a duplicate and my merging the duplicate in advance but not deleting the duplicate group until after I did the upload to ScholarSphere.

[EricDurante]

Ok, thanks for the clarification @anaelizabethenriquez. The fact that we don't know why this happened definitely gives me the heebie-jeebies. It's definitely possible that something went wrong as a result of the duplication, but the fact that the merge was done beforehand makes me think that it's unlikely. I don't know of any reason why the existence of the duplicate group would affect this process in any way.

@anaelizabethenriquez I'm also noticing now that this publication has two ScholarSphere open access locations as you can see in the admin UI: https://metadata.libraries.psu.edu/admin/publication/429421. They appear to correspond to two different works in ScholarSphere that look identical except for their IDs. Do you have any idea how that might have happened?

[EricDurante]

The two identical-looking works in ScholarSphere even have the exact same timestamps in their work histories, so it looks like RMD somehow performed the same deposit twice in a row even though it only has a record of having done it once..

[EricDurante]

RMD's logs also only show one deposit in ScholarSphere for this publication:

I, [2021-11-08T12:35:55.367989 #778] INFO -- : #<Faraday::Response:0x00005561c8703b98 @on_complete_callbacks=[], @env=#<Faraday::Env @method=:post @request_body="{\"metadata\":{\"title\":\"The pop-up against coronavirus project\",\"description\":\"\\u003cp\\u003eIn this essay I discuss the Pop-Up against Coronavirus Project, initiated by the Fondazione Tancredi di Barolo based in Turin, Italy. It is a research, conservation and educational foundation devoted to movable books, especially pop-up books. Their work with children is in conjunction with their museum of School and Children's books (Museo della Scuola e del Libro per l'Infanzia). When the outbreak of the coronavirus in Italy in late February 2020 prevented the academic conference they had organized from occurring, the foundation immediately turned their attention to working cross culturally with and for children, engaging Italian, Chinese and later Dutch artists and paper engineers to devise working models of different types of pop-ups. I give an account of the inception of the project, discuss the materials provided on their site, and examine some of the images of the homemade artifacts made by children and their families in Italy and China.\\u003c/p\\u003e\",\"published_date\":\"2021-06-01\",\"work_type\":\"article\",\"visibility\":\"open\",\"rights\":\"https://rightsstatements.org/page/InC/1.0/\",\"creators\":[{\"psu_id\":\"jxr67\",\"display_name\":\"Jacqueline Reid-Walsh\"}],\"identifier\":[\"https://doi.org/10.1353/JEU.2021.0010\"],\"subtitle\":\"Child-made movable books evoking smiles, tears, and hope\",\"publisher\":[\"Jeunesse: Young People, Texts, Cultures\"]},\"content\":[{\"file\":\"{\\\"id\\\":\\\"687ec63d-3c7d-45d6-a152-a73898e63c8a.pdf\\\",\\\"storage\\\":\\\"cache\\\",\\\"metadata\\\":{\\\"size\\\":1366622,\\\"filename\\\":\\\"Jeunesse11_13.1Reid-Walsh.pdf\\\",\\\"mime_type\\\":\\\"application/pdf\\\"}}\"}],\"depositor\":\"jxr67\",\"permissions\":{}}" @url=#<URI::HTTPS https://scholarsphere.psu.edu/api/v1/ingest> @request=#<Faraday::RequestOptions (empty)> @request_headers={"Content-Type"=>"application/json", "X-API-KEY"=>"dc412255d4ff8b562e9832d437315f67c40b2436500c76336e35ecc8323dfd542ab6513c3d05b5b0ceeb2f54ba999827", "User-Agent"=>"Faraday v1.8.0"} @ssl=#<Faraday::SSLOptions verify=true> @response=#<Faraday::Response:0x00005561c8703b98 ...> @response_headers={"date"=>"Mon, 08 Nov 2021 17:35:54 GMT", "content-type"=>"application/json; charset=utf-8", "transfer-encoding"=>"chunked", "connection"=>"keep-alive", "x-frame-options"=>"SAMEORIGIN", "x-xss-protection"=>"1; mode=block", "x-content-type-options"=>"nosniff", "x-download-options"=>"noopen", "x-permitted-cross-domain-policies"=>"none", "referrer-policy"=>"strict-origin-when-cross-origin", "vary"=>"Accept", "etag"=>"W/\"349b729c15f62c22b6a39a16ca6162e7\"", "cache-control"=>"max-age=0, private, must-revalidate", "x-request-id"=>"c363ebc231c3c51d710aca28592b0ae3", "x-runtime"=>"0.375770", "strict-transport-security"=>"max-age=15724800; includeSubDomains"} @status=200 @reason_phrase="OK" @response_body="{\"message\":\"Work was successfully created\",\"url\":\"/resources/aa576e87-1ee4-42be-93de-03f59d407893\"}">>

So it doesn't look like RMD actually repeated the ingest request to ScholarSphere's API, but I can't otherwise explain the duplication in ScholarSphere.

[EricDurante]

That deposit that was recorded in the logs corresponds to this work in ScholarSphere: https://scholarsphere.psu.edu/resources/aa576e87-1ee4-42be-93de-03f59d407893

So I can't tell how the other one (https://scholarsphere.psu.edu/resources/253f4ca9-823c-4993-a5c8-66fcf0077ef9) got created.

[EricDurante]

@rschenk I notice that we're not raising exceptions here if the open access location fails to save. So it seems like this could happen without rolling back the rest of the db transaction that records the 'success' status on the deposit. I'm grasping a little bit here, but do you see any way that this could have happened? I don't immediately see anything..

[anaelizabethenriquez]

OK, that's seriously weird, @EricDurante. I manually added one ScholarSphere URL for this item, and I'm pretty sure it would have been https://scholarsphere.psu.edu/resources/aa576e87-1ee4-42be-93de-03f59d407893. I've looked at that page before and seen just one. Could the ScholarSphere importer have run today and added the second one? If so, this is related to #354.

I suspect these two URLs are both for one deposit, with one being a version URL and one being a work URL. @srerickson can you confirm that?

[EricDurante]

@anaelizabethenriquez Ohhh - I see! Yes, that could explain everything about the apparent "duplication". The ScholarSphere importer would have run last night, so if ScholarSphere gave us another URL for that publication's DOI at that point, then RMD would have recorded it as another ScholarSphere open access location. That definitely makes sense to me.

However, it doesn't explain why we didn't get the open access location for the work when RMD made the deposit. 😕

[anaelizabethenriquez]

@EricDurante I haven't done as many additional test deposits as I would like, but the 3 more I've done have all worked properly. I will try to do a few more today and update you here.

[EricDurante]

Thanks, @anaelizabethenriquez

Very strange that we can neither reproduce nor explain this one. Paradoxically I'd feel a lot better if it was happening all of the time.