Re: [dspace-tech] : Manage bitstreams storage

[Nada Abo-Eita]

Hi Tim, 
 
Thank you for your reply. 
I would like to know if we use the local storage option, Is there any negative 
effects on the performance of retrieving the bitstreams  (i.e. slowness) ? 

-- 
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Collection getParentCommunityList()

[Monika Mevenkamp]

Well I guess _ i rephrase - I’d vote for hiding  :-) 

On another note - would it make sense to get away from names like 
parentCommunity 
parentCollection

in favor of parent  / parentList 

again looking ahead to the bright future where collections and communities 
become the same 

Monika

—
Monika Mevenkamp
Digital Repository Infrastructure Developer
Princeton University
Phone: 609-258-4161
Skype: mo-meven



> On May 18, 2016, at 5:58 PM, Tim Donohue  wrote:
> 
> Hi Monika,
> 
> Those are good questions. To clarify, I'm not recommending we add a new "map 
> collections" feature. I was just pointing out to Terry, that *at the Java API 
> level*, DSpace has supported the idea of a Collection having multiple parents 
> for some time.  That is not a change, it's just how the Java API has worked.  
> However, at the UI level, this feature has never been implemented because we 
> never had a clear use case for it (and I'm not exactly sure myself why the 
> API was built this way to begin with).
> 
> When it comes to the REST API, we'd then have a decision. Do we let it act 
> more like the Java API or do we just "hide" this feature of the Java API and 
> make the REST API look more like the current UIs.  I think this is the basics 
> of what Terry is asking in his #2.  I'm not sold on the fact that we need to 
> let the REST API even support this feature (it's definitely not a high 
> priority).
> I think the real issue here is just finding a solution to 
> https://jira.duraspace.org/browse/DS-2766 
> , which is more about just 
> figuring out what "parentCommunityList" was meant to do.
> 
> - Tim
> 
> On 5/18/2016 3:08 PM, Monika Mevenkamp wrote:
>> Right now DSpace has a conceptually clean structure, an almost perfect 
>> hierarchy, except where items are mapped to multiple collections.  So for 
>> example: it is clear what it means to show a collection in the UI. For a 
>> mapped item that is not necessarily true. Image styling different 
>> collections in different ways in a future flexible UI  - what style should 
>> be picked for a mapped item ? In other words - mapping things - means moving 
>> away from a hierarchy - means life will be more complicated.
>> 
>> My question here: Mapping Collection to multiple communities  — Is it worth 
>> it ?
>> 
>> What is the use case for mapping collections to multiple communities   ?
>> 
>> Can the same be achieved with solr and ‘virtual’ collections which could be 
>> defined as whatever matches some kind of query ?
>> 
>> What is the implication in terms of getting rid of the distinction between 
>> communities and collections ? 
>> That is a feature I am looking forward to: we have several communities with 
>> a single collection with few items.
>> 
>> Where does that position the DSPACE model in relation to the Portland Data 
>> Model ? 
>> 
>> My gut tells me to not to map collections. I don’t have a good overview of 
>> the wider DSPace world though.
>> But it would be  worthwhile discussing before hacking …
>> 
>> 
>> Monika
>> —
>> Monika Mevenkamp
>> Digital Repository Infrastructure Developer
>> Princeton University
>> Phone: 609-258-4161
>> Skype: mo-meven
>> 
>> 
>> 
>>> On May 18, 2016, at 12:33 PM, Terry Brady < 
>>> terry.br...@georgetown.edu 
>>> > wrote:
>>> 
>>> Tim,
>>> 
>>> Thanks for the explanation.
>>> 
>>> To implement #1, I recommend that we add the necessary hibernate 
>>> configuration logic to recursively traverse community2community.  Who could 
>>> advise on that change?
>>> 
>>> To implement #2, we would probably want to change the method return type to 
>>> return a list of lists: one list for each immediate community parent.
>>> 
>>> Terry
>>> 
>>> On Wed, May 18, 2016 at 7:39 AM, Tim Donohue < 
>>> tdono...@duraspace.org 
>>> > wrote:
>>> Hi Terry,
>>> 
>>> Some quick answers...
>>> I'm not sure of the correct answer to #1 myself (Peter Dietz, did you 
>>> create this behavior?). Since it's called a "List" though, it sounds to me 
>>> like the behavior in DSpace 5.x is more correct (that the intension may be 
>>> to locate the full location of the collection, similar to breadcrumbs). 
>>> As for #2, the API / database has always supported the "idea" of a 
>>> Collection existing in multiple locations (i.e. a "linked" Collection). 
>>> However, we've never found a reason to fully build this out with unit 
>>> tests, etc. So, it's a partially created concept, and it's never really 
>>> been proven to "work".  In addition, the UIs have never supported this 
>>> idea...at the UI level, a Collection only ever belongs to a single 
>>> Community.
>>> So, essentially, #2 would/should be treated as a new feature. The 
>>> groundwork is there in the API / database layer. But, it has never been 
>>> fully built out. It'd need a volunteer to dig in and implement this 

Re: [dspace-tech] Collection getParentCommunityList()

[Tim Donohue]

Hi Monika,

Those are good questions. To clarify, I'm not recommending we add a new 
"map collections" feature. I was just pointing out to Terry, that *at 
the Java API level*, DSpace has supported the idea of a Collection 
having multiple parents for some time.  That is not a change, it's just 
how the Java API has worked.  However, at the UI level, this feature has 
never been implemented because we never had a clear use case for it (and 
I'm not exactly sure myself why the API was built this way to begin with).


When it comes to the REST API, we'd then have a decision. Do we let it 
act more like the Java API or do we just "hide" this feature of the Java 
API and make the REST API look more like the current UIs.  I think this 
is the basics of what Terry is asking in his #2.  I'm not sold on the 
fact that we need to let the REST API even support this feature (it's 
definitely not a high priority).


I think the real issue here is just finding a solution to 
https://jira.duraspace.org/browse/DS-2766, which is more about just 
figuring out what "parentCommunityList" was meant to do.


- Tim


On 5/18/2016 3:08 PM, Monika Mevenkamp wrote:
Right now DSpace has a conceptually clean structure, an almost perfect 
hierarchy, except where items are mapped to multiple collections.  So 
for example: it is clear what it means to show a collection in the UI. 
For a mapped item that is not necessarily true. Image styling 
different collections in different ways in a future flexible UI  - 
what style should be picked for a mapped item ? In other words - 
mapping things - means moving away from a hierarchy - means life will 
be more complicated.


My question here: Mapping Collection to multiple communities  — Is it 
worth it ?


What is the use case for mapping collections to multiple communities   ?

Can the same be achieved with solr and ‘virtual’ collections which 
could be defined as whatever matches some kind of query ?


What is the implication in terms of getting rid of the distinction 
between communities and collections ?
That is a feature I am looking forward to: we have several communities 
with a single collection with few items.


Where does that position the DSPACE model in relation to the Portland 
Data Model ?


My gut tells me to not to map collections. I don’t have a good 
overview of the wider DSPace world though.

But it would be  worthwhile discussing before hacking …


Monika
—
Monika Mevenkamp
Digital Repository Infrastructure Developer
Princeton University
Phone: 609-258-4161
Skype: mo-meven



On May 18, 2016, at 12:33 PM, Terry Brady > wrote:


Tim,

Thanks for the explanation.

To implement #1, I recommend that we add the necessary hibernate 
configuration logic to recursively traverse community2community.  Who 
could advise on that change?


To implement #2, we would probably want to change the method return 
type to return a list of lists: one list for each immediate community 
parent.


Terry

On Wed, May 18, 2016 at 7:39 AM, Tim Donohue > wrote:


Hi Terry,

Some quick answers...

I'm not sure of the correct answer to #1 myself (Peter Dietz, did
you create this behavior?). Since it's called a "List" though, it
sounds to me like the behavior in DSpace 5.x is more correct
(that the intension may be to locate the full location of the
collection, similar to breadcrumbs).

As for #2, the API / database has always supported the "idea" of
a Collection existing in multiple locations (i.e. a "linked"
Collection). However, we've never found a reason to fully build
this out with unit tests, etc. So, it's a partially created
concept, and it's never really been proven to "work".  In
addition, the UIs have never supported this idea...at the UI
level, a Collection only ever belongs to a single Community.

So, essentially, #2 would/should be treated as a new feature. The
groundwork is there in the API / database layer. But, it has
never been fully built out. It'd need a volunteer to dig in and
implement this concept so that it's actually usable in the UIs. 
It also may require some refactoring at the REST API layer, as

you've noted.

- Tim

On 5/17/2016 1:03 PM, Terry Brady wrote:

I am investigating the following ticket:
https://jira.duraspace.org/browse/DS-2766

Here are my questions.
1. In the collections endpoint, of the REST api, what is the
intended behavior of expand=parentCommunityList?
2. In DSpace, can a collection exist in multiple communities?

Question 1. expand=parentCommunityList

In DSpace5x, the expand=parentCommunityList option returns the
full hierarchy of owing communities for a collection (all the
way to the top level community).

In DSpace 6x, this option returns the subcommunity that is an
immediate parent of the collection.

Assuming that this behavior is incorrect in DSpac

Re: [dspace-tech] Collection getParentCommunityList()

[Monika Mevenkamp]

Right now DSpace has a conceptually clean structure, an almost perfect 
hierarchy, except where items are mapped to multiple collections.  So for 
example: it is clear what it means to show a collection in the UI. For a mapped 
item that is not necessarily true. Image styling different collections in 
different ways in a future flexible UI  - what style should be picked for a 
mapped item ? In other words - mapping things - means moving away from a 
hierarchy - means life will be more complicated.

My question here: Mapping Collection to multiple communities  — Is it worth it ?

What is the use case for mapping collections to multiple communities   ?

Can the same be achieved with solr and ‘virtual’ collections which could be 
defined as whatever matches some kind of query ?

What is the implication in terms of getting rid of the distinction between 
communities and collections ? 
That is a feature I am looking forward to: we have several communities with a 
single collection with few items.

Where does that position the DSPACE model in relation to the Portland Data 
Model ? 

My gut tells me to not to map collections. I don’t have a good overview of the 
wider DSPace world though.
But it would be  worthwhile discussing before hacking …


Monika
—
Monika Mevenkamp
Digital Repository Infrastructure Developer
Princeton University
Phone: 609-258-4161
Skype: mo-meven



> On May 18, 2016, at 12:33 PM, Terry Brady  wrote:
> 
> Tim,
> 
> Thanks for the explanation.
> 
> To implement #1, I recommend that we add the necessary hibernate 
> configuration logic to recursively traverse community2community.  Who could 
> advise on that change?
> 
> To implement #2, we would probably want to change the method return type to 
> return a list of lists: one list for each immediate community parent.
> 
> Terry
> 
> On Wed, May 18, 2016 at 7:39 AM, Tim Donohue  > wrote:
> Hi Terry,
> 
> Some quick answers...
> I'm not sure of the correct answer to #1 myself (Peter Dietz, did you create 
> this behavior?). Since it's called a "List" though, it sounds to me like the 
> behavior in DSpace 5.x is more correct (that the intension may be to locate 
> the full location of the collection, similar to breadcrumbs). 
> As for #2, the API / database has always supported the "idea" of a Collection 
> existing in multiple locations (i.e. a "linked" Collection). However, we've 
> never found a reason to fully build this out with unit tests, etc. So, it's a 
> partially created concept, and it's never really been proven to "work".  In 
> addition, the UIs have never supported this idea...at the UI level, a 
> Collection only ever belongs to a single Community.
> So, essentially, #2 would/should be treated as a new feature. The groundwork 
> is there in the API / database layer. But, it has never been fully built out. 
> It'd need a volunteer to dig in and implement this concept so that it's 
> actually usable in the UIs.  It also may require some refactoring at the REST 
> API layer, as you've noted.
> 
> - Tim
> On 5/17/2016 1:03 PM, Terry Brady wrote:
>> I am investigating the following ticket:  
>> https://jira.duraspace.org/browse/DS-2766
>>  
>> 
>> Here are my questions.
>> 1. In the collections endpoint, of the REST api, what is the intended 
>> behavior of expand=parentCommunityList?
>> 2. In DSpace, can a collection exist in multiple communities?
>> 
>> Question 1. expand=parentCommunityList
>> 
>> In DSpace5x, the expand=parentCommunityList option returns the full 
>> hierarchy of owing communities for a collection (all the way to the top 
>> level community).
>> 
>> In DSpace 6x, this option returns the subcommunity that is an immediate 
>> parent of the collection.
>> 
>> Assuming that this behavior is incorrect in DSpace 6, the following 
>> configuration will need to be updated to follow the community2community 
>> hierarchy: 
>> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Collection.java#L81-L86
>>  
>> 
>> 
>> Question 2: Can a collection exist in multiple communities?
>> 
>> The following method in DSpace 5x could imply that a collection can exist in 
>> multiple communities:  
>> https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace-api/src/main/java/org/dspace/content/Collection.java#L1402
>>  
>> 
>> 
>> But, the REST API implies that there is a single "parentCommunity".
>> https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace-rest/src/main/java/org/dspace/rest/common/Collection.java#L136
>>  
>> 

Re: [dspace-tech] Re: Boolean default in Discovery search

[Tim Donohue]

Hi Jeff,

This change to boolean AND searching was made in the upcoming 6.0 
release.  See


https://jira.duraspace.org/browse/DS-2809

The actual code changes are here (and they are tiny):

https://github.com/DSpace/DSpace/pull/1106

- Tim

On 5/18/2016 11:47 AM, Jeffrey Sheldon wrote:

This might answer my question:

https://wiki.apache.org/solr/SchemaXml#Default_query_parser_operator

Is this the "correct" way to specify this change?


-Jeff


From: dspace-tech@googlegroups.com  on behalf of 
Jeffrey Sheldon 
Sent: Wednesday, May 18, 2016 11:43 AM
To: dspace-tech@googlegroups.com
Subject: [dspace-tech] Boolean default in Discovery search

Folks,

I noticed that the search.operator attribute in dspace.cfg became depreciated 
with Discovery.  However, I don't see a provision to define default search 
boolean logic.  Perhaps I'm missing something obvious?

Example searches (showing that SOLR honors capital boolean arguments included 
in the search keywords):

cow beef: 9924 results
cow OR beef: 9924 results
cow AND beef: 5375 results

My institution prefers that all searches to be based on AND and not OR as 
default.

The working theory is to enable the defaultFilterQueries area of 
config/spring/api/discovery.xml and include some sort of argument there, but I 
can't find any examples which support this theory.

Thoughts?


-Jeff

--
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.



--
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

--
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Collection getParentCommunityList()

[Tim Donohue]

Hi Terry,

On 5/18/2016 11:33 AM, Terry Brady wrote:

Tim,

Thanks for the explanation.

To implement #1, I recommend that we add the necessary hibernate 
configuration logic to recursively traverse community2community.  Who 
could advise on that change?


Sounds like we should verify the purpose of this setting first (with 
whoever added it...it doesn't seem to have documentation?). Maybe Peter 
Dietz?
Then, maybe get feedback from KevinVdV (or Atmire) on updating Hibernate 
as needed.




To implement #2, we would probably want to change the method return 
type to return a list of lists: one list for each immediate community 
parent.


Yes, that makes sense to me. As long as we validate the assumptions in 
#1 first.  We'd need to document this change in the REST API docs 
though, as it might affect anyone using "parentCommunityList" already.


In general here, I think we need more feedback on the intension of this 
param (maybe even try to track down in the codebase who added it, via 
GitHub "blame"?) . I'm not sure I even understand it. Until we do, it's 
hard to figure out how to proceed.


- Tim

--
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

--
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Re: Boolean default in Discovery search

[Jeffrey Sheldon]

This might answer my question:

https://wiki.apache.org/solr/SchemaXml#Default_query_parser_operator

Is this the "correct" way to specify this change?  


-Jeff


From: dspace-tech@googlegroups.com  on behalf of 
Jeffrey Sheldon 
Sent: Wednesday, May 18, 2016 11:43 AM
To: dspace-tech@googlegroups.com
Subject: [dspace-tech] Boolean default in Discovery search

Folks,

I noticed that the search.operator attribute in dspace.cfg became depreciated 
with Discovery.  However, I don't see a provision to define default search 
boolean logic.  Perhaps I'm missing something obvious?

Example searches (showing that SOLR honors capital boolean arguments included 
in the search keywords):

cow beef: 9924 results
cow OR beef: 9924 results
cow AND beef: 5375 results

My institution prefers that all searches to be based on AND and not OR as 
default.

The working theory is to enable the defaultFilterQueries area of 
config/spring/api/discovery.xml and include some sort of argument there, but I 
can't find any examples which support this theory.

Thoughts?


-Jeff

--
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Boolean default in Discovery search

[Jeffrey Sheldon]

Folks,

I noticed that the search.operator attribute in dspace.cfg became depreciated 
with Discovery.  However, I don't see a provision to define default search 
boolean logic.  Perhaps I'm missing something obvious?

Example searches (showing that SOLR honors capital boolean arguments included 
in the search keywords):

cow beef: 9924 results
cow OR beef: 9924 results
cow AND beef: 5375 results

My institution prefers that all searches to be based on AND and not OR as 
default.

The working theory is to enable the defaultFilterQueries area of 
config/spring/api/discovery.xml and include some sort of argument there, but I 
can't find any examples which support this theory.

Thoughts?


-Jeff

-- 
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Collection getParentCommunityList()

[Terry Brady]

Tim,

Thanks for the explanation.

To implement #1, I recommend that we add the necessary hibernate
configuration logic to recursively traverse community2community.  Who could
advise on that change?

To implement #2, we would probably want to change the method return type to
return a list of lists: one list for each immediate community parent.

Terry

On Wed, May 18, 2016 at 7:39 AM, Tim Donohue  wrote:

> Hi Terry,
>
> Some quick answers...
>
> I'm not sure of the correct answer to #1 myself (Peter Dietz, did you
> create this behavior?). Since it's called a "List" though, it sounds to me
> like the behavior in DSpace 5.x is more correct (that the intension may be
> to locate the full location of the collection, similar to breadcrumbs).
>
> As for #2, the API / database has always supported the "idea" of a
> Collection existing in multiple locations (i.e. a "linked" Collection).
> However, we've never found a reason to fully build this out with unit
> tests, etc. So, it's a partially created concept, and it's never really
> been proven to "work".  In addition, the UIs have never supported this
> idea...at the UI level, a Collection only ever belongs to a single
> Community.
>
> So, essentially, #2 would/should be treated as a new feature. The
> groundwork is there in the API / database layer. But, it has never been
> fully built out. It'd need a volunteer to dig in and implement this concept
> so that it's actually usable in the UIs.  It also may require some
> refactoring at the REST API layer, as you've noted.
>
> - Tim
> On 5/17/2016 1:03 PM, Terry Brady wrote:
>
> I am investigating the following ticket:
> 
> https://jira.duraspace.org/browse/DS-2766
>
> Here are my questions.
> 1. In the collections endpoint, of the REST api, what is the intended
> behavior of expand=parentCommunityList?
> 2. In DSpace, can a collection exist in multiple communities?
>
> Question 1. expand=parentCommunityList
>
> In DSpace5x, the expand=parentCommunityList option returns the full
> hierarchy of owing communities for a collection (all the way to the top
> level community).
>
> In DSpace 6x, this option returns the subcommunity that is an immediate
> parent of the collection.
>
> Assuming that this behavior is incorrect in DSpace 6, the following
> configuration will need to be updated to follow the community2community
> hierarchy:
> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Collection.java#L81-L86
>
> Question 2: Can a collection exist in multiple communities?
>
> The following method in DSpace 5x could imply that a collection can exist
> in multiple communities:
> 
> https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace-api/src/main/java/org/dspace/content/Collection.java#L1402
>
> But, the REST API implies that there is a single "parentCommunity".
>
> https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace-rest/src/main/java/org/dspace/rest/common/Collection.java#L136
>
> and a separate parentCommunityList
>
> https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace-rest/src/main/java/org/dspace/rest/common/Collection.java#L156
>
> What is the intended set of relationships to be supported?
>
> If a collection can exist in multiple communities, how should the REST api
> respond to "expand=parentCommunityList" option?
>
> If a collection can exist in multiple communities, how can this
> relationship be created in our UIs?
>
> Terry
>
> --
> Terry Brady
> Applications Programmer Analyst
> Georgetown University Library Information Technology
> https://www.library.georgetown.edu/lit/code
> 425-298-5498 (Seattle, WA)
> --
> 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 post to this group, send email to dspace-tech@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Tim Donohue
> Technical Lead for DSpace & DSpaceDirect
> DuraSpace.org | DSpace.org | DSpaceDirect.org
>
> --
> 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 post to this group, send email to dspace-tech@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Terry Brady
Applications Programmer Analyst
Georgetown University Library Information Technology
https://www.library.georgetown.edu/lit/code
425-298-5498 (Seattle, WA)

-- 
You received this message because you a

Re: [dspace-tech] Collection getParentCommunityList()

[Tim Donohue]

Hi Terry,

Some quick answers...

I'm not sure of the correct answer to #1 myself (Peter Dietz, did you 
create this behavior?). Since it's called a "List" though, it sounds to 
me like the behavior in DSpace 5.x is more correct (that the intension 
may be to locate the full location of the collection, similar to 
breadcrumbs).


As for #2, the API / database has always supported the "idea" of a 
Collection existing in multiple locations (i.e. a "linked" Collection). 
However, we've never found a reason to fully build this out with unit 
tests, etc. So, it's a partially created concept, and it's never really 
been proven to "work".  In addition, the UIs have never supported this 
idea...at the UI level, a Collection only ever belongs to a single 
Community.


So, essentially, #2 would/should be treated as a new feature. The 
groundwork is there in the API / database layer. But, it has never been 
fully built out. It'd need a volunteer to dig in and implement this 
concept so that it's actually usable in the UIs. It also may require 
some refactoring at the REST API layer, as you've noted.


- Tim

On 5/17/2016 1:03 PM, Terry Brady wrote:
I am investigating the following ticket: 
https://jira.duraspace.org/browse/DS-2766


Here are my questions.
1. In the collections endpoint, of the REST api, what is the intended 
behavior of expand=parentCommunityList?

2. In DSpace, can a collection exist in multiple communities?

Question 1. expand=parentCommunityList

In DSpace5x, the expand=parentCommunityList option returns the full 
hierarchy of owing communities for a collection (all the way to the 
top level community).


In DSpace 6x, this option returns the subcommunity that is an 
immediate parent of the collection.


Assuming that this behavior is incorrect in DSpace 6, the following 
configuration will need to be updated to follow the 
community2community hierarchy: 
https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Collection.java#L81-L86


Question 2: Can a collection exist in multiple communities?

The following method in DSpace 5x could imply that a collection can 
exist in multiple communities: 
https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace-api/src/main/java/org/dspace/content/Collection.java#L1402


But, the REST API implies that there is a single "parentCommunity".
https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace-rest/src/main/java/org/dspace/rest/common/Collection.java#L136

and a separate parentCommunityList
https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace-rest/src/main/java/org/dspace/rest/common/Collection.java#L156

What is the intended set of relationships to be supported?

If a collection can exist in multiple communities, how should the REST 
api respond to "expand=parentCommunityList" option?


If a collection can exist in multiple communities, how can this 
relationship be created in our UIs?


Terry

--
Terry Brady
Applications Programmer Analyst
Georgetown University Library Information Technology
https://www.library.georgetown.edu/lit/code
425-298-5498 (Seattle, WA)
--
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 post to this group, send email to dspace-tech@googlegroups.com 
.

Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.


--
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

--
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] XML Configurable workflow migration error

[Tim Donohue]

Alex,

Glad to hear it worked! Yes, you are correct, I mistyped that command in 
my response. The correct command *is*


./dspace database repair

We'll have to look into whether this command needs to be run for anyone 
who wants to later enable XML Configurable Workflow.


- Tim


On 5/18/2016 7:36 AM, Alex Fletcher wrote:

Tim:

Thanks, that worked, though the actual command I needed was:

./dspace database repair

Once that was run, I ran the "database migrate" command by hand, and 
it worked well with no complaints, and it's back online now.


On this -dev machine, we built the DB from scratch on a 5.2 install 
(we've bumped through 5.3, 5.4, and now onto 5.5). We have decided to 
use the configurable workflows, and I enabled them as per the 
documentation. When I worked through that, restarted/etc, that's when 
the checksum error (below) occurred.


Alex


On Tuesday, 17 May 2016 17:45:10 UTC-4, Tim Donohue wrote:

Hi Alex,

This sounds like you've previously run this migration against the
database, but the Flyway tool assigned a different "Migration
Checksum".

You should be able to get around this by running..

./dspace migrate repair

The "repair" command tells Flyway to ignore the old "checksum" and
replace it with the newly computed value.

However, I also wonder how you encountered this scenario.  Did you
happen to move this database from one server to another (sometimes
that causes a Flyway checksum mismatch at the DB level)?

- Tim


On 5/16/2016 9:55 AM, Alex Fletcher wrote:

I have been working to add configurable workflows to our test
DSpace implementation (v5.5). I set up the xmlui.xconf and the
modules/workflow.cfg file as per the documentation, and then ran
the tomcat restart which is supposed to migrate the DB automatically.

When I connect to the DSpace instance, it is a blank page, and
looking at the log file I see the following:



2016-05-16 10:37:04,907 ERROR
org.dspace.storage.rdbms.DatabaseManager @ SQL getDataSource Error -
java.sql.SQLException: Flyway migration error occurred
at

org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:430)
at

org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:338)
at

org.dspace.storage.rdbms.DatabaseManager.initialize(DatabaseManager.java:1373)
at

org.dspace.storage.rdbms.DatabaseManager.getDataSource(DatabaseManager.java:650)
at

org.dspace.storage.rdbms.DatabaseManager.getConnection(DatabaseManager.java:629)
at org.dspace.core.Context.init(Context.java:121)
at org.dspace.core.Context.(Context.java:95)
at

org.dspace.app.util.AbstractDSpaceWebapp.register(AbstractDSpaceWebapp.java:79)
at

org.dspace.app.util.DSpaceContextListener.contextInitialized(DSpaceContextListener.java:128)
at

org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4973)
at

org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at

org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672)
at

org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.flywaydb.core.api.FlywayException: Validate
failed. Found differences between applied migrations and
available migrations: Migration Checksum mismatch for migration
V1.1__Initial_DSpace_1.1_database_schema.sql: DB=1058944165,
Classpath=864087011
at org.flywaydb.core.Flyway.doValidate(Flyway.java:912)
at org.flywaydb.core.Flyway.access$400(Flyway.java:50)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:817)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:811)
at org.flywaydb.core.Flyway.execute(Flyway.java:1171)
at org.flywaydb.core.Flyway.migrate(Flyway.java:811)
at

org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:419)
... 21 more


On a whim, I tried running the migrate by han

Re: [dspace-tech] XML Configurable workflow migration error

[Alex Fletcher]

Tim:

Thanks, that worked, though the actual command I needed was:

./dspace database repair

Once that was run, I ran the "database migrate" command by hand, and it 
worked well with no complaints, and it's back online now.

On this -dev machine, we built the DB from scratch on a 5.2 install (we've 
bumped through 5.3, 5.4, and now onto 5.5). We have decided to use the 
configurable workflows, and I enabled them as per the documentation. When I 
worked through that, restarted/etc, that's when the checksum error (below) 
occurred.

Alex


On Tuesday, 17 May 2016 17:45:10 UTC-4, Tim Donohue wrote:
>
> Hi Alex,
>
> This sounds like you've previously run this migration against the 
> database, but the Flyway tool assigned a different "Migration Checksum".
>
> You should be able to get around this by running..
>
> ./dspace migrate repair
>
> The "repair" command tells Flyway to ignore the old "checksum" and replace 
> it with the newly computed value.
>
> However, I also wonder how you encountered this scenario.  Did you happen 
> to move this database from one server to another (sometimes that causes a 
> Flyway checksum mismatch at the DB level)? 
>
> - Tim
>
> On 5/16/2016 9:55 AM, Alex Fletcher wrote:
>
> I have been working to add configurable workflows to our test DSpace 
> implementation (v5.5). I set up the xmlui.xconf and the 
> modules/workflow.cfg file as per the documentation, and then ran the tomcat 
> restart which is supposed to migrate the DB automatically.
>
> When I connect to the DSpace instance, it is a blank page, and looking at 
> the log file I see the following:
>
>
>
> 2016-05-16 10:37:04,907 ERROR org.dspace.storage.rdbms.DatabaseManager @ 
> SQL getDataSource Error -
> java.sql.SQLException: Flyway migration error occurred
> at 
> org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:430)
> at 
> org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:338)
> at 
> org.dspace.storage.rdbms.DatabaseManager.initialize(DatabaseManager.java:1373)
> at 
> org.dspace.storage.rdbms.DatabaseManager.getDataSource(DatabaseManager.java:650)
> at 
> org.dspace.storage.rdbms.DatabaseManager.getConnection(DatabaseManager.java:629)
> at org.dspace.core.Context.init(Context.java:121)
> at org.dspace.core.Context.(Context.java:95)
> at 
> org.dspace.app.util.AbstractDSpaceWebapp.register(AbstractDSpaceWebapp.java:79)
> at 
> org.dspace.app.util.DSpaceContextListener.contextInitialized(DSpaceContextListener.java:128)
> at 
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4973)
> at 
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5467)
> at 
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
> at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
> at 
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632)
> at 
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:672)
> at 
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1862)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.flywaydb.core.api.FlywayException: Validate failed. Found 
> differences between applied migrations and available migrations: Migration 
> Checksum mismatch for migration 
> V1.1__Initial_DSpace_1.1_database_schema.sql: DB=1058944165, 
> Classpath=864087011
> at org.flywaydb.core.Flyway.doValidate(Flyway.java:912)
> at org.flywaydb.core.Flyway.access$400(Flyway.java:50)
> at org.flywaydb.core.Flyway$1.execute(Flyway.java:817)
> at org.flywaydb.core.Flyway$1.execute(Flyway.java:811)
> at org.flywaydb.core.Flyway.execute(Flyway.java:1171)
> at org.flywaydb.core.Flyway.migrate(Flyway.java:811)
> at 
> org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:419)
> ... 21 more
>
>
> On a whim, I tried running the migrate by hand and got the same error.
>
> What's gone wrong here and how can we resolve this to continue our 
> implementation work?
>
> Alex
> -- 
> 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...@googlegroups.com .
> To post to this group, send email to dspac...@googlegroups.com 
> .
> Visit this

Re: [dspace-tech] wildcard policy admin tool

[Sean Carte]

Thanks, Hilton; unfortunately not relevant as Arthur pointed out: the
wildcard admin tool only works at the item/bitstream level.

Sean

On 18 May 2016 at 13:41, Hilton Gibson  wrote:

> Hi Sean,
>
> I recently made some videos, see;
> https://www.youtube.com/watch?v=jopOjr2ZblA
> https://www.youtube.com/watch?v=rWTWpUDyBg4
>
> Perhaps they can help.
>
> Cheers
>
> hg
>
> *Hilton Gibson*
> Stellenbosch University Library
> *http://orcid.org/-0002-2992-208X
> *
>
>
> On 18 May 2016 at 13:22, Sean Carte  wrote:
>
>> Thanks, Arthur; that makes sense.
>>
>> Sean
>>
>> On 18 May 2016 at 13:07, Arthur Smith  wrote:
>>
>>> Hi Sean
>>>
>>> I believe the wildcard admin tool only works on the individual
>>> item/bitstream level, it doesn't allow you to change a
>>> collection's/community's permissions.
>>>
>>> Note also that if you choose to remove permissions, in my experience at
>>> least, this will remove *all* permissions from an item/bitstream within
>>> a collection.
>>>
>>> Best,
>>> Arthur
>>>
>>>
>>> On 18/05/2016 11:53, Sean Carte wrote:
>>>
>>> Am I correct in thinking I can use the wildcard policy admin tool to
>>> add/remove a group's permission to add items to a set of collections?
>>>
>>> For example, I have a group of epersons named Step2; I want to give them
>>> permissions to archive items, that is, approve items in the collection step
>>> 2 phase so that the items appear in the collection.
>>>
>>> So I go to the wildcard policy admin tool and make the following
>>> selections:
>>>
>>> Group: Step2
>>> Action: Add
>>> Content Type: item
>>> Collection: (I select all collections)
>>>
>>> and click Add policies.
>>>
>>> From the logs I can see items being updated, but when I go to a
>>> collection's authorisations, and look at the workflow step 2 (e.g.
>>> COLLECTION_9_WORKFLOW_STEP_2), the group I expected to appear in the
>>> Members is not there. No new policy has been added to the list of policies
>>> either.
>>>
>>> Have I misunderstood the purpose of the wildcard policy admin tool, or
>>> am I just doing something wrong?
>>>
>>> Sean
>>> --
>>>
>>> --
>>> 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 post to this group, send email to dspace-tech@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/dspace-tech.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> 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 post to this group, send email to dspace-tech@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/dspace-tech.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>>
>> --
>> 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 post to this group, send email to dspace-tech@googlegroups.com.
>> Visit this group at https://groups.google.com/group/dspace-tech.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>


--

-- 
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Found problem in collection home page browsing results

[Hilton Gibson]

Hi Shiva,

Please refer to:
http://wiki.lib.sun.ac.za/index.php/SUNScholar/Browse_Indexes#WARNING:
The remedy is to upgrade, if I am correct.

Cheers

hg


*Hilton Gibson*
Stellenbosch University Library
*http://orcid.org/-0002-2992-208X
*


On 18 May 2016 at 13:46, Shiva Kumara  wrote:

> Dear All Members,
>
>
>
> I am working with Dspace 5.1 version on ubuntu 14 production server. I
> found problem in collection home page, when I browse by issue
> date/author/title/subject in a particular collection home page, the result
> will be displayed from all communities and collections items not by
> particular collection home page results. How I would fix this issue with
> your valuable solutions.
>
> Thank you
>
> Shivakumara RM
>
> Digital Library Analyst
>
> ISEC, Bangalore
>
> --
> 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 post to this group, send email to dspace-tech@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Found problem in collection home page browsing results

[Shiva Kumara]

Dear All Members,

 

I am working with Dspace 5.1 version on ubuntu 14 production server. I 
found problem in collection home page, when I browse by issue 
date/author/title/subject in a particular collection home page, the result 
will be displayed from all communities and collections items not by 
particular collection home page results. How I would fix this issue with 
your valuable solutions. 

Thank you

Shivakumara RM

Digital Library Analyst

ISEC, Bangalore

-- 
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] wildcard policy admin tool

[Hilton Gibson]

Hi Sean,

I recently made some videos, see;
https://www.youtube.com/watch?v=jopOjr2ZblA
https://www.youtube.com/watch?v=rWTWpUDyBg4

Perhaps they can help.

Cheers

hg

*Hilton Gibson*
Stellenbosch University Library
*http://orcid.org/-0002-2992-208X
*


On 18 May 2016 at 13:22, Sean Carte  wrote:

> Thanks, Arthur; that makes sense.
>
> Sean
>
> On 18 May 2016 at 13:07, Arthur Smith  wrote:
>
>> Hi Sean
>>
>> I believe the wildcard admin tool only works on the individual
>> item/bitstream level, it doesn't allow you to change a
>> collection's/community's permissions.
>>
>> Note also that if you choose to remove permissions, in my experience at
>> least, this will remove *all* permissions from an item/bitstream within
>> a collection.
>>
>> Best,
>> Arthur
>>
>>
>> On 18/05/2016 11:53, Sean Carte wrote:
>>
>> Am I correct in thinking I can use the wildcard policy admin tool to
>> add/remove a group's permission to add items to a set of collections?
>>
>> For example, I have a group of epersons named Step2; I want to give them
>> permissions to archive items, that is, approve items in the collection step
>> 2 phase so that the items appear in the collection.
>>
>> So I go to the wildcard policy admin tool and make the following
>> selections:
>>
>> Group: Step2
>> Action: Add
>> Content Type: item
>> Collection: (I select all collections)
>>
>> and click Add policies.
>>
>> From the logs I can see items being updated, but when I go to a
>> collection's authorisations, and look at the workflow step 2 (e.g.
>> COLLECTION_9_WORKFLOW_STEP_2), the group I expected to appear in the
>> Members is not there. No new policy has been added to the list of policies
>> either.
>>
>> Have I misunderstood the purpose of the wildcard policy admin tool, or am
>> I just doing something wrong?
>>
>> Sean
>> --
>>
>> --
>> 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 post to this group, send email to dspace-tech@googlegroups.com.
>> Visit this group at https://groups.google.com/group/dspace-tech.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> 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 post to this group, send email to dspace-tech@googlegroups.com.
>> Visit this group at https://groups.google.com/group/dspace-tech.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
> --
> 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 post to this group, send email to dspace-tech@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] wildcard policy admin tool

[Sean Carte]

Thanks, Arthur; that makes sense.

Sean

On 18 May 2016 at 13:07, Arthur Smith  wrote:

> Hi Sean
>
> I believe the wildcard admin tool only works on the individual
> item/bitstream level, it doesn't allow you to change a
> collection's/community's permissions.
>
> Note also that if you choose to remove permissions, in my experience at
> least, this will remove *all* permissions from an item/bitstream within a
> collection.
>
> Best,
> Arthur
>
>
> On 18/05/2016 11:53, Sean Carte wrote:
>
> Am I correct in thinking I can use the wildcard policy admin tool to
> add/remove a group's permission to add items to a set of collections?
>
> For example, I have a group of epersons named Step2; I want to give them
> permissions to archive items, that is, approve items in the collection step
> 2 phase so that the items appear in the collection.
>
> So I go to the wildcard policy admin tool and make the following
> selections:
>
> Group: Step2
> Action: Add
> Content Type: item
> Collection: (I select all collections)
>
> and click Add policies.
>
> From the logs I can see items being updated, but when I go to a
> collection's authorisations, and look at the workflow step 2 (e.g.
> COLLECTION_9_WORKFLOW_STEP_2), the group I expected to appear in the
> Members is not there. No new policy has been added to the list of policies
> either.
>
> Have I misunderstood the purpose of the wildcard policy admin tool, or am
> I just doing something wrong?
>
> Sean
> --
>
> --
> 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 post to this group, send email to dspace-tech@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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 post to this group, send email to dspace-tech@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>



--

-- 
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] wildcard policy admin tool

[Arthur Smith]

Hi Sean

I believe the wildcard admin tool only works on the individual 
item/bitstream level, it doesn't allow you to change a 
collection's/community's permissions.


Note also that if you choose to remove permissions, in my experience at 
least, this will remove *all* permissions from an item/bitstream within 
a collection.


Best,
Arthur

On 18/05/2016 11:53, Sean Carte wrote:
Am I correct in thinking I can use the wildcard policy admin tool to 
add/remove a group's permission to add items to a set of collections?


For example, I have a group of epersons named Step2; I want to give 
them permissions to archive items, that is, approve items in the 
collection step 2 phase so that the items appear in the collection.


So I go to the wildcard policy admin tool and make the following 
selections:


Group: Step2
Action: Add
Content Type: item
Collection: (I select all collections)

and click Add policies.

From the logs I can see items being updated, but when I go to a 
collection's authorisations, and look at the workflow step 2 (e.g. 
COLLECTION_9_WORKFLOW_STEP_2), the group I expected to appear in the 
Members is not there. No new policy has been added to the list of 
policies either.


Have I misunderstood the purpose of the wildcard policy admin tool, or 
am I just doing something wrong?


Sean
--

--
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 post to this group, send email to dspace-tech@googlegroups.com 
.

Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.


--
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] wildcard policy admin tool

[Sean Carte]

Am I correct in thinking I can use the wildcard policy admin tool to
add/remove a group's permission to add items to a set of collections?

For example, I have a group of epersons named Step2; I want to give them
permissions to archive items, that is, approve items in the collection step
2 phase so that the items appear in the collection.

So I go to the wildcard policy admin tool and make the following selections:

Group: Step2
Action: Add
Content Type: item
Collection: (I select all collections)

and click Add policies.

>From the logs I can see items being updated, but when I go to a
collection's authorisations, and look at the workflow step 2 (e.g.
COLLECTION_9_WORKFLOW_STEP_2), the group I expected to appear in the
Members is not there. No new policy has been added to the list of policies
either.

Have I misunderstood the purpose of the wildcard policy admin tool, or am I
just doing something wrong?

Sean
--

-- 
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 post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.