Hugo

2015-12-18 10:56 GMT+01:00 Lizz Jennings <E.Jennings@bath.ac.uk>:

Hi Hugo,

 

I wrote the Reviewed Queue plugin to manage our data archive, where we want to mark items as having been checked, but don’t want to release the metadata publicly until the associated paper is published.

 

I’d have no plans to adapt it to process conference papers – we only use one type of EPrint in our repository, and it is designed to work with the plugins we use for a data repository – ReCollect, CoinDOI and so on.

 

All the code is on GitHub – the only bug I know to exist for the way I use it is a missing phrase which will be in the next version (when I’ve fixed some other issues I have).  You’d be very welcome to base a sorting tool on that if it’s helpful:

 

https://github.com/eprintsug/reviewed_queue

 

Adam’s produced two videos on making a Bazaar package, so you would be able to share your work back with the community:

 

http://wiki.eprints.org/w/index.php/Training_Video:Export_Plugin_Bazaar_Package

 

http://wiki.eprints.org/w/index.php/Training_Video:New_Field_Bazaar_Package

 

Hope that helps!

 

Lizz

 

--

Lizz Jennings BA MSc ACLIP MCLIP (Revalidated 2015)

Technical Data Officer

The Library 4.10, University of Bath, Bath, BA2 7AY UK

Ext. 3570 (External 01225 383570)

E.Jennings@bath.ac.uk

Research Data Management: http://www.bath.ac.uk/research/data

 

 

From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-bounces@ecs.soton.ac.uk] On Behalf Of Hugo F. Alrøe
Sent: 18 December 2015 09:27
To: eprints-tech@ecs.soton.ac.uk
Subject: [EP-tech] Re: Editoring speed problem and Review queue option

 

Thank you for the advice, Yuri. 

 

It would be very good if the speed problem could be solved, and if I get some indication that this can and will be done, we can wait for this solution. As I said, it is only recently that we tracked down what we believe is the cause of the slow speed in review work.

 

I should say that we are still running on EPrints 3.3.10, because the upgrade to 3.3.14 involves upgrading the Linux system and we have been a bit reluctant to do this before we had to. But we have plans to do the upgrade soon, to be better able to use the Bazaar options Coversheets and IRstats 2.

 

Hugo

Hugo F. Alrøe

Email: hugo.f.alroe@gmail.com

Phone: +45 61775599

 

2015-12-18 10:10 GMT+01:00 Yuri <yurj@alfa.it>:

Isn't better to fix the slowness? i wouldn't depend, on big projects, on
plugins found on Bazaar if I'm not sure they're well mantained.

Il 18/12/2015 09:39, Hugo F. Alrøe ha scritto:
> Hi
>
> We have experienced speed problems when editoring on our archive
> Organic Eprints (www.orgprints.org <http://www.orgprints.org>). We

> have +30 editors with responsibilities for different countries and
> projects, and some of them, but only some, experience that the system
> is very slow when they are working with the review buffer. Search etc.
> is not affected.
>
> I finally found out that the number of editorial rights restrictions
> affect the speed of showing the review buffer substantially. We have
> some 16 eprint types (yes, I know, too many, but the archive has many
> different kinds of eprints), and one of these (conference submissions)
> has to be handled by different editors. This means most of our
> national editors have 15 eprint types (all but the conference
> submissions) in their editorial rights restrictions, to avoid
> conference submissions being moved into the archive prematurely by the
> national editors. Some editors have a number of countries and projects
> as well in their editorial rights restrictions, which means that
> showing the buffer can be veeery slow (like, go get a cup of coffee,
> start on something else, and forget about it).
>
> To solve this problem, I think about handling the conference
> submissions differently. In the ePrints Bazaar I found the Reviewed
> queue package, which offers a functionality that potentially can meet
> this purpose by establishing an additional review buffer.
>
> For this to work however, eprints of type conference submissions
> should go automatically into this additional buffer. Is this possible?
> And if so, how?
>
> And preferably it should be possible to restrict most editors from
> seeing this additional buffer. We have editors with different powers
> already (some being able to modify the subject trees to e.g. add new
> research affiliations). But I am not sure whether the additional
> buffer established by Reviewed queue can be allocated to a specific
> editor type. Is this possible?
>
> Can anybody help on these questions?
>
> Best regards
> Hugo Alroe
> Initiator (in 2002) of Organic Eprints and presently temporary archive
> administrator.
>

> Email: hugo.f.alroe@gmail.com <mailto:hugo.f.alroe@gmail.com>
>
>
>
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive: http://www.eprints.org/tech.php/
> *** EPrints community wiki: http://wiki.eprints.org/
> *** EPrints developers Forum: http://forum.eprints.org/


*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

 

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/