[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[EP-tech] Re: Editoring speed problem and Review queue option
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:
Adam?s produced two videos on making a Bazaar package, so you would be able to share your work back with the community:
Hope that helps!
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 at bath.ac.uk<mailto:E.Jennings at bath.ac.uk>
Research Data Management: http://www.bath.ac.uk/research/data
From: eprints-tech-bounces at ecs.soton.ac.uk [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Hugo F. Alr?e
Sent: 18 December 2015 09:27
To: eprints-tech at 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 F. Alr?e
Email: hugo.f.alroe at gmail.com<mailto:hugo.f.alroe at gmail.com>
Phone: +45 61775599
2015-12-18 10:10 GMT+01:00 Yuri <yurj at alfa.it<mailto:yurj at 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:
> We have experienced speed problems when editoring on our archive
> Organic Eprints (www.orgprints.org<http://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
> Email: hugo.f.alroe at gmail.com<mailto:hugo.f.alroe at gmail.com> <mailto:hugo.f.alroe at gmail.com<mailto:hugo.f.alroe at 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/
-------------- next part --------------
An HTML attachment was scrubbed...