Re: [dspace-tech] for a specific community I want to publish without approval, what im doing wrong ?

[Paul Münch]

Hello,

if you want accept items without any workflow steps, then do not setup a
workflow group in the target collection. You do not have to configure
anything for it in the 'workflow.xml'.

Kind regards,

Paul Münch

Am 06.11.18 um 01:21 schrieb Damian:
> im working with dspace 6.0 xmlui  mirage2 theme
>
>  modifiy workflow.xml 
>
> for a specific community (Reposit/4) , i want to publish without
> approval, all others community get default workflow
>
> but im doing something wrong because is not working 
>
> 
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
> 
> ColeccQGral
> 
> 
> 
> 
> 
> 
> 
> -- 
> All messages to this mailing list should adhere to the DuraSpace Code
> of Conduct: https://duraspace.org/about/policies/code-of-conduct/
> ---
> 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.

-- 
Philipps-Universität Marburg | UB 
Digitale Dienste | Deutschhausstraße 9 | D018
Tel. +49 06421 28-24624  
--

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
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.


signature.asc
Description: OpenPGP digital signature

[dspace-tech] for a specific community I want to publish without approval, what im doing wrong ?

[Damian]

im working with dspace 6.0 xmlui  mirage2 theme

 modifiy workflow.xml 

for a specific community (Reposit/4) , i want to publish without approval, 
all others community get default workflow

but im doing something wrong because is not working 







 





 

ColeccQGral








-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
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] HTTPS and SOLR

[Cameron, Jacob]

Can I have SOLR secured under a wildcard SSL certificate? I’ve installed our 
cert and forced HTTPS I’m tomcat, but SOLR keeps giving a 302 error now and 
when I browse it it tells me that it’s an invalid cert. I haven’t been able to 
figure a way around it. We aren’t using Apache HTTPD to configure our ports.

--

Please excuse any typing errors or grammatical mistakes. I’m sending this 
message from a mobile device.

Jake Cameron, BCS(UNB)
Systems Support Specialist III
Information Systems and Technical Services University of Lethbridge Library
Phone:(403)329-2756
This e-mail, including any and all attachments, is only for the use of the 
intended recipient(s) and may contain information that is confidential or 
privileged. If you are not the intended recipient, you are advised that any 
dissemination, copying or other use of this e-mail is prohibited. Please notify 
the sender of the error in communication by return e-mail and destroy all 
copies of this e-mail. Thank you.

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
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] Re: DSpace 5.9 performance

[kardeiz]

Hi Alan,

Thanks for the note and sharing your solution.

Another possible solution would be to just ignore caching entirely for the 
search pages.

It seems like whatever time is saved in the Cocoon processing pipeline by 
having this cache would be far outweighed by not having to do all the 
database queries to look up bundles and bitstreams. As far as I can tell, 
discovery pages don't really need any bitstream information besides what is 
in the Solr index. And it seems like these bundle/bitstream queries are 
performed even when there is a valid cache (it is my understanding that the 
caching is for later Cocoon processing steps).

I'm not a Cocoon expert, though, and I haven't read through all the 
DSpaceValidity code, so I might be wrong.

Jacob

On Monday, November 5, 2018 at 1:49:00 PM UTC-6, Alan Orth wrote:
>
> Good work, Jacob.
>
> I think I'll test this on our DSpace 5.8 site as well. Our solution is 
> different: we just severely rate limit and dissuade bots from accessing 
> dynamic pages like discover, browse, search-filter, and most-popular 
> (specifically, the ones in communities and collections, because the 
> site-wide robots.txt can't use wildcards). See our nginx configuration 
> template:
>
>
> https://github.com/ilri/rmg-ansible-public/commit/1aadbb839659bcb2326fbc9bb0b2b67bf13ed7f0
>
> Cheers,
>
> On Thu, Nov 1, 2018 at 11:24 PM > wrote:
>
>> PR is at https://github.com/DSpace/DSpace/pull/2254.
>>
>> Jacob
>>
>> On Thursday, November 1, 2018 at 4:00:45 PM UTC-5, kar...@gmail.com 
>> wrote:
>>>
>>> Hi Tim,
>>>
>>> I wasn't sure if my assumption that only bitstreams in the ORIGINAL 
>>> bundle are relevant to search results cache invalidation would be valid for 
>>> all users of DSpace. 
>>>
>>> I'll go ahead and open a PR though.
>>>
>>> Jacob
>>>
>>>
>>>
>>> On Thursday, November 1, 2018 at 3:47:13 PM UTC-5, Tim Donohue wrote:

 Hi Jacob,

 Would you be willing to submit a GitHub Pull Request with the code 
 changes you've made?  Or, create a ticket in our ticketing system (
 https://jira.duraspace.org/browse/DS) to describe the problem and 
 attach the fix? (You can request a JIRA account by just emailing 
 sysa...@duraspace.org.)

 Most of the development / bug fixes and improvements to DSpace come 
 from community members like yourself (and situations just like this -- 
 where someone figures out a fix that is generally applicable to others).  
 More on our code contribution process can be found at: 
 https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines 

 - Tim

 On Thu, Nov 1, 2018 at 3:43 PM  wrote:

> I've figured this out!
>
> `org.dspace.app.xmlui.utils.DSpaceValidity`, which is used in 
> `AbstractSearch` to cache results, actually looks up and keys all 
> bundles, 
> then all bitstreams, for each item the search results.
>
> It seems reasonable to assume (at least for our use case) that only 
> bitstreams in the ORIGINAL bundle are relevant to search results (i.e., a 
> change in a public file is a reason to invalidate the cache, but a change 
> in non-ORIGINAL files is not).
>
> I've added a method to `DSpaceValidity` called 
> `addIfItemOnlyAddOriginalBundles`, which only keys ORIGINAL bundles for 
> an 
> `Item`, and defers to the existing `add` for everything else. I then 
> updated `AbstractSearch` to call my `addIfItemOnlyAddOriginalBundles` 
> when 
> it is adding the search result DSOs to the validity object.
>
> This has dropped my SQL query total from over 9000 to about 60, and 
> the page loads relatively fast.
>
> Unfortunately, this won't help those who have lots of bitstreams in 
> their ORIGINAL bundle, but that is perhaps unavoidable.
>
> Jacob
>
>
>
> On Wednesday, October 31, 2018 at 11:52:25 AM UTC-5, kar...@gmail.com 
> wrote:
>
>> Hi all,
>>
>> We are running DSpace 5.9 XMLUI with Tomcat 7 and Java 8 on a RHEL 7 
>> server, with a small-ish collection of items (about 20,000). We are 
>> running 
>> production with Oracle 12, but I have replicated the same issue with 
>> Postgresql 9.2.
>>
>> We have recently noticed some very long page load times. Any given 
>> discover/search page can take 2-7 seconds to load, and when there is 
>> even a 
>> moderate amount of traffic (e.g., when a bot is indexing the site at 
>> about 
>> 10 requests per second), page load times can take 30-60 seconds or 
>> longer.
>>
>> We have made the changes suggested at 
>> https://wiki.duraspace.org/display/DSDOC5x/Performance+Tuning+DSpace 
>> for both Tomcat and PostgreSQL.
>>
>> Our production site has been customized extensively, but I was able 
>> to replicate the issue with an untouched DSpace 5.9 build using the 
>> default 
>> Mirage theme with 

Re: [dspace-tech] Re: DSpace 5.9 performance

[Alan Orth]

Good work, Jacob.

I think I'll test this on our DSpace 5.8 site as well. Our solution is
different: we just severely rate limit and dissuade bots from accessing
dynamic pages like discover, browse, search-filter, and most-popular
(specifically, the ones in communities and collections, because the
site-wide robots.txt can't use wildcards). See our nginx configuration
template:

https://github.com/ilri/rmg-ansible-public/commit/1aadbb839659bcb2326fbc9bb0b2b67bf13ed7f0

Cheers,

On Thu, Nov 1, 2018 at 11:24 PM  wrote:

> PR is at https://github.com/DSpace/DSpace/pull/2254.
>
> Jacob
>
> On Thursday, November 1, 2018 at 4:00:45 PM UTC-5, kar...@gmail.com wrote:
>>
>> Hi Tim,
>>
>> I wasn't sure if my assumption that only bitstreams in the ORIGINAL
>> bundle are relevant to search results cache invalidation would be valid for
>> all users of DSpace.
>>
>> I'll go ahead and open a PR though.
>>
>> Jacob
>>
>>
>>
>> On Thursday, November 1, 2018 at 3:47:13 PM UTC-5, Tim Donohue wrote:
>>>
>>> Hi Jacob,
>>>
>>> Would you be willing to submit a GitHub Pull Request with the code
>>> changes you've made?  Or, create a ticket in our ticketing system (
>>> https://jira.duraspace.org/browse/DS) to describe the problem and
>>> attach the fix? (You can request a JIRA account by just emailing
>>> sysa...@duraspace.org.)
>>>
>>> Most of the development / bug fixes and improvements to DSpace come from
>>> community members like yourself (and situations just like this -- where
>>> someone figures out a fix that is generally applicable to others).  More on
>>> our code contribution process can be found at:
>>> https://wiki.duraspace.org/display/DSPACE/Code+Contribution+Guidelines
>>>
>>> - Tim
>>>
>>> On Thu, Nov 1, 2018 at 3:43 PM  wrote:
>>>
 I've figured this out!

 `org.dspace.app.xmlui.utils.DSpaceValidity`, which is used in
 `AbstractSearch` to cache results, actually looks up and keys all bundles,
 then all bitstreams, for each item the search results.

 It seems reasonable to assume (at least for our use case) that only
 bitstreams in the ORIGINAL bundle are relevant to search results (i.e., a
 change in a public file is a reason to invalidate the cache, but a change
 in non-ORIGINAL files is not).

 I've added a method to `DSpaceValidity` called
 `addIfItemOnlyAddOriginalBundles`, which only keys ORIGINAL bundles for an
 `Item`, and defers to the existing `add` for everything else. I then
 updated `AbstractSearch` to call my `addIfItemOnlyAddOriginalBundles` when
 it is adding the search result DSOs to the validity object.

 This has dropped my SQL query total from over 9000 to about 60, and the
 page loads relatively fast.

 Unfortunately, this won't help those who have lots of bitstreams in
 their ORIGINAL bundle, but that is perhaps unavoidable.

 Jacob



 On Wednesday, October 31, 2018 at 11:52:25 AM UTC-5, kar...@gmail.com
 wrote:

> Hi all,
>
> We are running DSpace 5.9 XMLUI with Tomcat 7 and Java 8 on a RHEL 7
> server, with a small-ish collection of items (about 20,000). We are 
> running
> production with Oracle 12, but I have replicated the same issue with
> Postgresql 9.2.
>
> We have recently noticed some very long page load times. Any given
> discover/search page can take 2-7 seconds to load, and when there is even 
> a
> moderate amount of traffic (e.g., when a bot is indexing the site at about
> 10 requests per second), page load times can take 30-60 seconds or longer.
>
> We have made the changes suggested at
> https://wiki.duraspace.org/display/DSDOC5x/Performance+Tuning+DSpace
> for both Tomcat and PostgreSQL.
>
> Our production site has been customized extensively, but I was able to
> replicate the issue with an untouched DSpace 5.9 build using the default
> Mirage theme with XMLUI.
>
> The issue is the same with both Oracle and PostgreSQL (PostgreSQL
> seems a little bit better).
>
> I have tried changing from Java 8 to Java 7.
>
> I have bumped up the database connection pool size to 300.
>
> Digging through the logs is difficult, since the problem only really
> emerges under (moderate) load.
>
> However, I was able to track a single page request (to /discover), and
> noticed that there were over 9000 individual SQL queries (for a single 
> page
> load) that looked like:
>
> DEBUG org.dspace.storage.rdbms.DatabaseManager @ Running query "SELECT
> * FROM MetadataValue WHERE resource_id= ? and resource_type_id = ? ORDER 
> BY
> metadata_field_id, place"  with parameters: 144458,0
>
> (The resource_type_id `0` is for bitstreams.)
>
> I *think* (but could be wrong) that this is the source of our
> performance problem; that the database is just getting bogged down with so
> many requests. Looking 

Re: [dspace-tech] Show and tell: DSpace Statistics API

[Bruno Nocera Zanette]

Nice job, Alan!
It may be very handy for our research group and the systems we mantain.
Thanks!
Em qui, 1 de nov de 2018 às 11:40, Alan Orth  escreveu:
>
> Dear list,
>
> We have recently been doing some integration with our DSpace repository using 
> the REST API. Eventually we realized that it would be nice to be able to use 
> the item views and downloads from the Solr statistics core, but those are not 
> exposed by any externally accessible APIs. I wrote a small, lightweight 
> Python-based tool that runs locally on the DSpace server to periodically 
> index the Solr statistics core and expose the statistics via a simple API. 
> And it's fast!
>
> The tool is called "dspace-statistics-api" and you can find the source code, 
> documentation, and deployment instructions on GitHub:
>
> https://github.com/ilri/dspace-statistics-api
>
> You can see it in running on the public development instance of our DSpace 
> repository:
>
> https://dspacetest.cgiar.org/rest/statistics
>
> I hope this is useful to some people and I would be very happy for comments, 
> suggestions, and pull requests (see my list of TODOs in the project).
>
> Thank you!
>
> --
> Alan Orth
> alan.o...@gmail.com
> https://picturingjordan.com
> https://englishbulgaria.net
> https://mjanja.ch
> "In heaven all the interesting people are missing." ―Friedrich Nietzsche
>
> --
> All messages to this mailing list should adhere to the DuraSpace Code of 
> Conduct: https://duraspace.org/about/policies/code-of-conduct/
> ---
> 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.



-- 
Bruno Nocera Zanette
+55 41 2-2508

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
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] Re: CC License step failing

[jca3]

Hi everyone,

Does anyone is having some problem with CC again? In my repository the cc 
step just show "no license" option.

Thanks.

Em segunda-feira, 2 de julho de 2018 17:05:00 UTC-3, Javier Távara escreveu:
>
> Hi Rob!
> Our DSpace instances are having problems again due to an invalid SSL cert.
>
> I hope you can take a look soon.
>
> Disabling CC step in DSpace meanwhile...
>
> Thank you!
>
> Javier.
>
>
> El martes, 3 de abril de 2018, 16:05:02 (UTC-5), Rob Myers escribió:
>>
>> Thank you everyone who reported this.
>>
>> I am going to mark this as fixed.
>>
>> We should move the API to https-only at some point in the future to help 
>> keep user information private, but it shouldn't happen without warning.
>>
>> Thanks again.
>>
>> - Rob.
>>
>> On Tuesday, April 3, 2018 at 11:34:44 AM UTC-7, George Kozak wrote:
>>>
>>> Rob:
>>> Thank you.  Going back to http has fixed the problem for us at Cornell 
>>> University.
>>> George Kozak
>>> Cornell University
>>>
>>> On Tue, Apr 3, 2018 at 2:01 PM, Rob Myers  
>>> wrote:
>>>
 Heya all.

 I have re-enabled http for now. I will put a redirect back in place at 
 some point in the future, with suitable warning.

 For anyone who changing the url to be https didn't help, does switching 
 back to http improve things?

 - Rob.

 On Monday, April 2, 2018 at 5:13:57 PM UTC-7, Rob Myers wrote:
>
> Heya Javier.
>
> Thank you for checking this.
>
> There is a 301 redirect in place from http to https.
>
> The old server had Varnish publicly accessible on port 80, which I 
> assumed was an error so I didn't recreate that (we were meant to have 
> switched everything to https a couple of years ago!).
>
> If changing to https fixes the issue, this would explain it.
>
> Is it easy to change cc.api.rooturl to https, or is that going to be a 
> pain for people?
>
> Thank you again.
>
> - Rob.
>
> On Monday, April 2, 2018 at 4:59:23 PM UTC-7, Javier Távara wrote:
>>
>> Thank you for the update Rob.
>>
>> Any redirection is being applied from non-SSL to SSL? Was the same 
>> before the update?
>>
>> I changed my settings (dspace.cfg) to use SSL:
>>
>> # The url to the web service API
>> cc.api.rooturl = https://api.creativecommons.org/rest/1.5
>>
>> And it works now :)
>>
>> - Javier.
>>
>> El lunes, 2 de abril de 2018, 18:51:16 (UTC-5), Rob Myers escribió:
>>>
>>> Heya everyone, Rob from Creative Commons here.
>>>
>>> I'm very sorry that our API isn't working with DSpace at the moment. 
>>> I upgraded the server that the API runs on, and the problem that you 
>>> are 
>>> seeing wasn't caught by my tests.
>>>
>>> If I call the API simply via the command line, e.g.:
>>>
>>> curl -d 
>>> "answers=enysaUntitledA.
>>>  
>>> N. 
>>> Otherhttps://example.com/untitled"
>>>  
>>> https://api.creativecommons.org/rest/1.5/license/standard/issue
>>>
>>> Then I do get back an xml block, e.g.:
>>>
>>> 
>>> 
>>>   http://creativecommons.org/licenses/by-sa/4.0/
>>> 
>>>   Attribution-ShareAlike 4.0 
>>> International
>>>   false
>>>   
>>> http://creativecommons.org/ns#; xmlns:rdf="
>>> http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
>>>   http://purl.org/dc/elements/1.1/; rdf:about="
>>> https://example.com/untitled;>UntitledA.
>>>  
>>> N. Otherhttp://creativecommons.org/licenses/by-sa/4.0/"/>>> rdf:about="http://creativecommons.org/licenses/by-sa/4.0/;>
>>> http://creativecommons.org/ns#DerivativeWorks"/>
>>> http://creativecommons.org/ns#Distribution"/>
>>> http://creativecommons.org/ns#Reproduction"/>
>>> http://creativecommons.org/ns#Attribution"/>
>>> http://creativecommons.org/ns#Notice"/>
>>> http://creativecommons.org/ns#ShareAlike
>>> "/>
>>>   
>>> 
>>>   
>>>   
>>> http://creativecommons.org/ns#; xmlns:rdf="
>>> http://www.w3.org/1999/02/22-rdf-syntax-ns#;>
>>>   http://creativecommons.org/licenses/by-sa/4.0/
>>> ">
>>> http://creativecommons.org/ns#DerivativeWorks"/>
>>> http://creativecommons.org/ns#Distribution"/>
>>> http://creativecommons.org/ns#Reproduction"/>
>>> http://creativecommons.org/ns#Attribution"/>
>>> http://creativecommons.org/ns#Notice"/>
>>> http://creativecommons.org/ns#ShareAlike
>>> "/>
>>>   
>>> 
>>>   
>>>   http://creativecommons.org/licenses/by-sa/4.0/;>http://i.creativecommons.org/l/by-sa/4.0/88x31.png"/>>> xmlns:dct="http://purl.org/dc/terms/; 
>>> property="dct:title">Untitled by http://creativecommons.org/ns#; href="https://example.com/untitled; 
>>> property="cc:attributionName" rel="cc:attributionURL">A. N. Other 
>>> is 
>>> licensed under 

Re: [dspace-tech] WORM submissions?

[Tony Brian Albers]

Thanks Claudia, I remembered that.

Our challenge is that sometimes the owner/administrator of a collection
should not be able to delete things.

/tony

On Mon, 2018-11-05 at 12:57 +0100, Claudia Jürgen wrote:
> Hello Tony,
> 
> this is the default behavior. A Submitter can only edit items in his
> personal workspace.
> Once he submitted them and they are in the workflow and/or accepted
> he
> can not edit the items anymore.
> 
> Hope this helps
> 
> Claudia Jürgen
> 
> 
> Am 02.11.2018 um 10:45 schrieb Tony Brian Albers:
> > No, not about actual living beings, but Write Once Read Many.
> > 
> > Is it possible to make a collection only accept deposits and not
> > let
> > the owner delete what he/she has deposited?
> > 
> > TIA
> > 
> > /tony
> > 
> > --
> > Tony Albers
> > Systems Architect
> > Systems Director, National Cultural Heritage Cluster
> > Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
> > Tel: +45 2566 2383 / +45 8946 2316
> > 
> 
> --
> Claudia Juergen
> Eldorado
> 
> Technische Universität Dortmund
> Universitätsbibliothek
> Vogelpothsweg 76
> 44227 Dortmund
> 
> Tel.: +49 231-755 40 43
> Fax: +49 231-755 40 32
> claudia.juer...@tu-dortmund.de
> www.ub.tu-dortmund.de
> 
> Wichtiger Hinweis: Die Information in dieser E-Mail ist vertraulich.
> Sie ist ausschließlich für den Adressaten bestimmt. Sollten Sie nicht
> der für diese E-Mail bestimmte Adressat sein, unterrichten Sie bitte
> den Absender und vernichten Sie diese Mail. Vielen Dank.
> Unbeschadet der Korrespondenz per E-Mail, sind unsere Erklärungen
> ausschließlich final rechtsverbindlich, wenn sie in herkömmlicher
> Schriftform (mit eigenhändiger Unterschrift) oder durch Übermittlung
> eines solchen Schriftstücks per Telefax erfolgen.
> 
> Important note: The information included in this e-mail is
> confidential. It is solely intended for the recipient. If you are not
> the intended recipient of this e-mail please contact the sender and
> delete this message. Thank you. Without prejudice of e-mail
> correspondence, our statements are only legally binding when they are
> made in the conventional written form (with personal signature) or
> when such documents are sent by fax.
> 

-- 
-- 
Tony Albers
Systems Architect
Systems Director, National Cultural Heritage Cluster
Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 2566 2383 / +45 8946 2316

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
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] WORM submissions?

[Claudia Jürgen]

Hello Tony,

this is the default behavior. A Submitter can only edit items in his
personal workspace.
Once he submitted them and they are in the workflow and/or accepted he
can not edit the items anymore.

Hope this helps

Claudia Jürgen


Am 02.11.2018 um 10:45 schrieb Tony Brian Albers:

No, not about actual living beings, but Write Once Read Many.

Is it possible to make a collection only accept deposits and not let
the owner delete what he/she has deposited?

TIA

/tony

--
Tony Albers
Systems Architect
Systems Director, National Cultural Heritage Cluster
Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 2566 2383 / +45 8946 2316



--
Claudia Juergen
Eldorado

Technische Universität Dortmund
Universitätsbibliothek
Vogelpothsweg 76
44227 Dortmund

Tel.: +49 231-755 40 43
Fax: +49 231-755 40 32
claudia.juer...@tu-dortmund.de
www.ub.tu-dortmund.de

Wichtiger Hinweis: Die Information in dieser E-Mail ist vertraulich. Sie ist 
ausschließlich für den Adressaten bestimmt. Sollten Sie nicht der für diese 
E-Mail bestimmte Adressat sein, unterrichten Sie bitte den Absender und 
vernichten Sie diese Mail. Vielen Dank.
Unbeschadet der Korrespondenz per E-Mail, sind unsere Erklärungen 
ausschließlich final rechtsverbindlich, wenn sie in herkömmlicher Schriftform 
(mit eigenhändiger Unterschrift) oder durch Übermittlung eines solchen 
Schriftstücks per Telefax erfolgen.

Important note: The information included in this e-mail is confidential. It is 
solely intended for the recipient. If you are not the intended recipient of 
this e-mail please contact the sender and delete this message. Thank you. 
Without prejudice of e-mail correspondence, our statements are only legally 
binding when they are made in the conventional written form (with personal 
signature) or when such documents are sent by fax.

--
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
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] WORM submissions?

[Tony Brian Albers]

On Fri, 2018-11-02 at 11:56 +0100, Michael Plate wrote:
> Hi Tony,
> 
> 
> Am 02.11.18 um 10:45 schrieb Tony Brian Albers:
> > No, not about actual living beings, but Write Once Read Many.
> > 
> > Is it possible to make a collection only accept deposits and not
> > let
> > the owner delete what he/she has deposited?
> 
> […]
> 
> it is possible, if I understand you correct.
> We use a LDAP-based group wich can only submit to one collection and
> there is no read access by default.
> 
> I think it was this way, but you have to fiddle around a bit...
> - create a collection
>  after that, assign roles - you should have a COLLECTION_XXX_SUBMIT
> and
>  COLLECTION_XXX_DEFAULT_READ group after
> - add some steps for the people to work with the workflow
> - use Access Control / Authorizations and add a new policy "ADD" for
> the
>   group or users who should submit
> - set DEFAULT_ITEM_READ and DEFAULT_BITSTREAM_READ to the people
> doing
>   the workflow
> - remove READ for Anonymous
> 
> after submission and workflow you have to move the item to the target
> collection, check "Inherit policies" and move it.
> 
> I hope this is the right way, I struggled a bit with it.
> 
> 


Thanks Michael,

That looks doable, but pretty inconvenient -I'll have a closer look.

/tony
-- 
-- 
Tony Albers
Systems Architect
Systems Director, National Cultural Heritage Cluster
Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 2566 2383 / +45 8946 2316

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
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.