EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #10344

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] Remove versions support from EPrints

Hi Yuri,
Yes, on occasion I have observed users doing this.  Having the succeeds value set (for the new item) also means the original item cannot typically be found by search.  I think this is because its causes the old item's metadata_visibility field to be automatically updated to 'no_search', (which does not get reverted if the the new version or it gets moved out of the live archive but is not retired*). What I have typically done is add the succeeds field to the workflow but made sure only admins or possibly even just I can see this field to edit.  Even if only admins can see it I have also made sure the help text is always expanded and includes something like "DO NOT CHANGE UNLESS YOU KNOW WHAT YOU ARE DOING."  Here is an example of where I have limited access to just me: 

<epc:if test="$current_user{username} = 'drn'">
    <component>
        <field ref="succeeds"/>
    </component>
</epc:if>

Alternatively, an admin restriction could be:

<epc:if test="$current_user{usertype} = 'admin'">

This might be better than using:

<epc:if test="$STAFF_ONLY = 'TRUE'">
As that will also include editors as well as admins.  I think there may even be a way to check whether the current user has a specific permission but I cannot remember the syntax off the top of my head.
I think there has always been some dissonance between what a user thinks creating a new version means and what you actually get if you produce a new version.  Here are the things that will happen if you create a new version: 

1. The new version will get its succeeds field set.
2. One the new version is moved to the live archive, the old version will no longer be searchable do to its metadata_visibility being set to 'no_search'.  It will only become searchable again if the new item is retired or deleted. I don't think has always been the case and older EPrints versions the old item may have never become searchable again once the new item was moved to the live archive. 3. Assuming no change to the summary_page citation, a list of all the versions in the chain will be listed towards the bottom of the abstract.summary page.
Here are some use cases for versions, where you would want the above behaviour: A. A new edition of a book.  You quite often see this with academic textbooks, as the field has moved on between editions.  You want the user to find the textbook that is most up to date. B. A new edition of a technical report (aka monograph).  If this describes a specification, you want to make sure the user gets the latest specification, not one that may have since been deprecated.
One case a new version is probably not appropriate is a conference/workshop item, which has been written up as a full journal article.  "Use as template", may be appropriate here, as a lot of the metadata may be the same, so this saves time entering it again.  However these two publications are separate entities and not new versions based on the way EPrints treats versions.
One thing that EPrints does not do out of the box is make it easy to link to other EPrints and explain their contextual relationship. Related URLs allows you do this in an informal way, although there are no useful related URL types for this by default.  You can add your own itemref field so you could link to other EPrints but that would probably need to be part of a compound field that allows you to specify the relationship with the other item.  There is no standard accepted way for doing this on EPrints and it is not something I commonly see. 

Regards

David Newman
*In the past I have looked at how you might sort out succeeds and metadata_visibility fields when users are creating and then subsequently deleting/retiring/returning to inbox new versions. This is a tricky problem, as there are many different scenarios. One particularly tricky scenario is when the middle version is deleted. 

On 25/03/2026 7:41 am, Yuri wrote:

CAUTION: This e-mail originated outside the University of Southampton.

CAUTION: This e-mail originated outside the University of Southampton.

Great, custom user role worked like a charm.

A related question: if a user make a revision inside its workarea and
then delete the first version record (he can), in the second version
record the "succeeds" field hold a reference to the deleted item.
Usually I set the "succeeds" field to NULL using a command line db
client. Is there a way to manage the "succeeds" fields using the web
interface? I'm thinking about the record interface which seems a low
level interface to the eprint record.

 My idea is to disable versioning for items in working area, but can
this be a problem for users that creates the entire chain of versions
and then publish all of it together?

Il 24/03/26 13:12, David R Newman ha scritto:

Hi Yuri,

I have also experience the mis-use of the "New Version" button. Often
the conflation with the "Use as template".  I don't think how you
disable this button has changed much if at all between 3.3.15 and the
latest version of 3.4.  You could just hide the button from the
Actions tab by adding the following to a config file under the
archive's cfg/cfg.d/ directory:
$c->{plugins}->{"Screen::EPrint::NewVersion"}->{appears}->{eprint_actions} 
= undef;

Alternatively, ou could ciompletely disable the scre



en plugin

$c->{plugins}->{"Screen::EPrint::NewVersion"}->{params}->{disable} = 1;

I don't think there is any risk to completely disabling this screen
plugin, so I would probably go for the latter.  However, if you have a
specific case where editors (and admin) can create new versions but
regular users should not then you would not want to completely disable
this screen plugin.  In that case you probably want to remove a
standard user from having the following permissions:

eprint/inbox/derive_version:owner
eprint/buffer/derive_version:owner
eprint/archive/derive_version:owner
eprint/deletion/derive_version:owner

This can be done by adding the following to a configuration file
(starting "z_" to ensure it is loaded after user_roles.pl) in your
archives cfg/cfg.d/ file:

push @{$c->{user_roles}->{user}}, qw{
    -eprint/inbox/derive_version:owner
    -eprint/buffer/derive_version:owner
    -eprint/archive/derive_version:owner
    -eprint/deletion/derive_version:owner
};

Regards

David Newman

On 24/03/2026 10:32, Yuri wrote:


CAUTION: This e-mail originated outside the University of Southampton.

CAUTION: This e-mail originated outside the University of Southampton.

Hi!

 EPrints 3.3.15 here.

 For our users, versions are confusing and often are misused. Often it
happens that the user make a mistake, submit to the buffer and then
(lazy) do a version to avoid reinserting the metadata again. So we find
there's a stale version linked to the good one and the buffer is also
filled with 2 items...

 We would like to hide the version functionality, at least for the
users. Then, as editor, we can link the real versions when we find there 
are (using db queries, there's no other way I know).

 Thanks!
*** Options: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.eprints.org%2Fw%2FEprints-tech_Mailing_List&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7C765a31a2b99f42688edc08de8a50787d%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C639100275460791059%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oVt7IVZ0puRUUot4DMMpaLMC6ajRhgqafF02mtUFFbU%3D&reserved=0 *** Archive: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eprints.org%2Ftech.php%2F&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7C765a31a2b99f42688edc08de8a50787d%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C639100275460845683%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=S%2FCZa9vuALtetI%2B5Da1tjA6R2RpP1EVJUkjbrsI1fs4%3D&reserved=0 *** EPrints community wiki: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.eprints.org%2F&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7C765a31a2b99f42688edc08de8a50787d%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C639100275460894204%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nEvOO%2BeSnOlbXO0Bb2vDy5ysZEYGeBI%2Bz7JQ4%2FPK0xs%3D&reserved=0 



*** Options: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.eprints.org%2Fw%2FEprints-tech_Mailing_List&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7C765a31a2b99f42688edc08de8a50787d%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C639100275460929249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pVXmZGzFNUqTAhhnaMAvvXXDIctrh51rKIQzB5UUjGQ%3D&reserved=0
*** Archive: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.eprints.org%2Ftech.php%2F&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7C765a31a2b99f42688edc08de8a50787d%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C639100275460968258%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gyLTaXSnqQ%2F7qsoywdzm7g38qDd4dCAwDtt0bZbi2Zw%3D&reserved=0
*** EPrints community wiki: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.eprints.org%2F&data=05%7C02%7Ceprints-tech%40ecs.soton.ac.uk%7C765a31a2b99f42688edc08de8a50787d%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C639100275461003124%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sciD957HXCX1%2FFDeskngaHl8wX2okkMhb8Lg5uGY57I%3D&reserved=0