Hi all, i now tested i again in 3.1 and its the same as in 3.0 I placed a Jira issue https://jira.duraspace.org/browse/DS-1514 like helix advice a few mails ago.
Regards, Marco Am 28.01.2013 09:43, schrieb helix84: > On Mon, Jan 28, 2013 at 8:29 AM, <marco.we...@kesslernetworks.de> > wrote: >> Am 18.01.2013 12:52, schrieb helix84: >>> On Fri, Jan 18, 2013 at 11:36 AM, <marco.we...@kesslernetworks.de> >>> wrote: >>>> Now what have i done. I created an item and imported it in OAI >>>> Solr >>>> search. >>> >>> What do you mean OAI Solr search? I assume you mean the "oai" Solr >>> core? "search" is a different Solr core, used for Discovery. >> >> With OAI Solr search i meant i imported the items in Solr so that a >> query on >> OAI can deliver the data getting it from the Solr ... hope i'm right >> here. > > Yes, that is the "oai" Solr core and you've done well. > >>>> The simple archive and the csv file shows no difference between >>>> the two >>>> states except of the dc.description.provenance. >>>> The unpacked AIP shows a difference between the two mets.xml >>>> files. >>>> That tells me, that only over AIP i can handle the embargo >>>> settings, or? >>> >>> Yes, as I wrote in my previous email. >>> Old embargo = bitstream authorizations + embargo terms in metadata >>> (so >>> SAF import should recognize it) >>> 3.0 embargo = bitstream resource policies (so probably only AIP >>> would >>> recognize it - it's part of METS) >> >> Ok so the old embargo should work, but what is SAF ? Can't find >> something in >> the documentation. >> Unfortunately i don't have enough time to test it because it was >> just nice >> to have and not must have criteria. >> Maybe in a later step i will get back to this. The step is planed >> but i can >> not tell when. > > Sorry, SAF is just a name for the format used in the original > importer > ([dspace]/bin/dspace import/export). > >>>> So i had the idea now to restore/replace it with the AIP i created >>>> as the >>>> item was in "not private" state and it have to be in that state >>>> after >>>> replacing it. >>>> Unfortunately it replaces the item but the "not private" state was >>>> not >>>> applied to the item. >>>> I set the "not private" state in XMLUI manually and imported the >>>> AIP i >>>> created as the item was in the "private" state and this works in >>>> parts. >>>> In parts means the item is withdrawn but in "not private" state >>>> after >>>> that. >>>> That means replacing an item that is in "not private" state with >>>> the >>>> "private" state item works the other way round not. >>>> To see the difference between the withdrawn item that is in "not >>>> private" >>>> state i put it manually in "private" state, exported it as AIP, >>>> unzipped, >>>> and diff the two mets.xml ... no changes that shows me what i have >>>> to set >>>> so >>>> get the item in "private"state. >>> >>> >>> Thanks for the testing, you may have found a bug. I didn't try it >>> myself (exporting/importing items with embargo via AIP), so I can't >>> explain it. If noone else answers in the next few days, you should >>> file a Jira issue to make sure it's addressed (either explained if >>> it's supposed to work that way, or fixed if it's not). >> >> >> Ok no one had answered to this mail so i will file a Jira issue. >> >> >>>> org.dspace.authorize.AuthorizeException: To withdraw item must be >>>> COLLECTION_ADMIN or have REMOVE authorization on owning Collection >>> >>> >>> This sounds pretty straightforward - did you use a correct value >>> for >>> the -e flag? E.g. a site admin eperson? >> >> >> Yes, sure i only have one account the site admin i created following >> the >> installation documentation. >> And yes i used the -e flag but in long version >> --eperson=my.m...@adress.de > > Sorry, I can't think of anything else that could have gone wrong > there. > >> Ok, i hope i can find a bit spare time to place a Jira issue the >> next day >> for that and i'll post the link to that. > > > Regards, > ~~helix84 > > Compulsory reading: DSpace Mailing List Etiquette > https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
