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.
Am 28.01.2013 09:43, schrieb helix84:
> On Mon, Jan 28, 2013 at 8:29 AM, <marco.weiss@...>
>> Am 18.01.2013 12:52, schrieb helix84:
>>> On Fri, Jan 18, 2013 at 11:36 AM, <marco.weiss@...>
>>>> Now what have i done. I created an item and imported it in OAI
>>> 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
> 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
>>>> 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
>>> SAF import should recognize it)
>>> 3.0 embargo = bitstream resource policies (so probably only AIP
>>> 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
> ([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
>>>> replacing it.
>>>> Unfortunately it replaces the item but the "not private" state was
>>>> 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
>>>> In parts means the item is withdrawn but in "not private" state
>>>> That means replacing an item that is in "not private" state with
>>>> "private" state item works the other way round not.
>>>> To see the difference between the withdrawn item that is in "not
>>>> state i put it manually in "private" state, exported it as AIP,
>>>> and diff the two mets.xml ... no changes that shows me what i have
>>>> to set
>>>> 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
>>> the -e flag? E.g. a site admin eperson?
>> Yes, sure i only have one account the site admin i created following
>> installation documentation.
>> And yes i used the -e flag but in long version
> Sorry, I can't think of anything else that could have gone wrong
>> 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.
> Compulsory reading: DSpace Mailing List Etiquette