EPrints Technical Mailing List Archive
Message: #03692
< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First
[EP-tech] Re: Restricting export of field based on value of another field
- To: eprints-tech@ecs.soton.ac.uk
- Subject: [EP-tech] Re: Restricting export of field based on value of another field
- From: "Field A.N." <af05v@ecs.soton.ac.uk>
- Date: Wed, 17 Dec 2014 11:14:37 +0000
Hi John How about creating a new field to store abstracts, called (e.g. restricted_abstract) and use that in the workflow instead of the default abstract field? You can then use eprint_fields_automatic to copy the value into the default abstract field when it's allowed to be open. You'd have to check that none of the 'dump this record' exporter (e.g. XML, Multiline CSV) export it (or are not available publicly). I believe there is flag that is set on the metadata field to tell it not to be part of the XML export, which you'd need to set. Alternatively, there's the 'virtual' flag on a metadata field that means it doesn't get stored in the database at all, but you can define functions around it. If you redefined the abstract field as virtual, you may be able to control its behaviour effectively with function. I've only every used these for rendering things (see https://github.com/gobfrey/tweepository/blob/master/cfg/cfg.d/z_tweepository_libs.pl lines 313 to 316). -- Adam Field Business Relationship and Community Manager EPrints Services On 17 Dec 2014, at 10:35, John Salter wrote: > Hi, > We have a requirement to (sometimes) embargo the abstract for some etheses. > > We have a boolean field that allows a student to: > - always show the abstract > - embargo the abstract when files are embargoed > > Changing the display of this information on the summary page is easy enough (change eprint_render.pl), but quite a few of the Export plugins reference the abstract field directly. > > I could create copies of all the Export plugins that reference the abstract field, but this seems inefficient. > > Is there a simple way of unsetting a field of a dataobject each time the dataobject is used, but without actually writing that change to the database? > > Cheers, > John > > > > *** 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/
- Follow-Ups:
- [EP-tech] Re: Restricting export of field based on value of another field
- From: "Field A.N." <af05v@ecs.soton.ac.uk>
- [EP-tech] Re: Restricting export of field based on value of another field
- References:
- [EP-tech] Restricting export of field based on value of another field
- From: John Salter <J.Salter@leeds.ac.uk>
- [EP-tech] Restricting export of field based on value of another field
- Prev by Date: [EP-tech] Re: Restricting export of field based on value of another field
- Next by Date: [EP-tech] Re: Restricting export of field based on value of another field
- Previous by thread: [EP-tech] Restricting export of field based on value of another field
- Next by thread: [EP-tech] Re: Restricting export of field based on value of another field
- Index(es):