[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] Does 'can_clone' work correctly?



I've thought about this a little more:
> I'd be tempted to go down the EP_TRIGGER_BEFORE_COMMIT route
I've decided that I wouldn't go down this route.
I'd create a new screen plugin:
    EPrints::Plugin::Screen::EPrint::LocalUseAsTemplate
Alias the existing UseAsTemplate to this one and update the action_use_as_template method to resolve incorrectly cloned fields.
This would be less work for the server than a commit trigger, as it would only be active when the UseAsTemplate screen was being processed.

Cheers,
John


From: eprints-tech-bounces at ecs.soton.ac.uk [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of John Salter
Sent: 16 May 2017 10:33
To: eprints-tech at ecs.soton.ac.uk
Subject: Re: [EP-tech] Does 'can_clone' work correctly?

Hi Matt,
I've just checked 'Use as Template' too - seems to work as expected.

> trigger on status chance
I'd be tempted to go down the EP_TRIGGER_BEFORE_COMMIT route, and check the revision number of the EPrint (I'm not sure if rev_number will be undef, or 0 before the first commit).

Good luck tracing the issue - I'm intrigued!

Cheers,
John

From: eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk> [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Matthew Brady
Sent: 15 May 2017 23:36
To: eprints-tech at ecs.soton.ac.uk<mailto:eprints-tech at ecs.soton.ac.uk>
Subject: Re: [EP-tech] Does 'can_clone' work correctly?

Hi John,

Thanks for that, but... users are using the 'Use as template', (rather than 'New Version') which clones the record, but has no linkage to the original version.

Looks like I need to start digging in the debug again,

I haven't got any triggers/automatic fields etc set up, but that gives me an idea, if I cannot get clone sorted out, maybe a trigger on status chance, to wipe the fields.. it's a bit hackey, but would get the job done :(

Cheers

Matt.

From: eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk> [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of John Salter
Sent: Monday, 15 May 2017 6:28 PM
To: eprints-tech at ecs.soton.ac.uk<mailto:eprints-tech at ecs.soton.ac.uk>
Subject: Re: [EP-tech] Does 'can_clone' work correctly?

Hi Matt,
I've just created test fields on a 3.3.10 repository, and when using the 'New version' button, the fields DO NOT get cloned. Things seem to work as expected/intended, using the field definitions you used.

Do you have any automatic fields that might be setting this data (so although it looks 'cloned' it's getting set independently)?
Do you have any triggers that might be doing anything?
Could you (not quite sure how) have the same field definition more than once (with the later version having a different 'can_clone' setting)?
Have you got something that's overriding the 'clone' method?

Possibly adding debug statements to EPrints::DataObj::EPrint::clone might be the quickest way forward...

Cheers,
John

From: eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk> [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Matthew Brady
Sent: 15 May 2017 05:48
To: 'eprints-tech at ecs.soton.ac.uk' <eprints-tech at ecs.soton.ac.uk<mailto:eprints-tech at ecs.soton.ac.uk>>
Subject: [EP-tech] Does 'can_clone' work correctly?

Hi All,


BUMP...

Anyone have any ideas how to set a field parameter as 'can_clone=>0' for field definitions within the eprints_fields.pl file?

We have some fields that are visible to editorial staff only, which flag various details about the items in the repository.
The problem is, when an item is cloned, these extra 'unknown to the end user' fields are also cloned and set, with what appear to be valid notes/data...

I thought the 'can_clone' property would stop these data fields from being copied across, but alas, nothing I have tried has appeared to work.

I would rather not have to disable the clone button, but if that's the only option then that's how I have to do it...

Cheers

Matt.




From: eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk> [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Matthew Brady
Sent: Friday, 28 April 2017 5:00 PM
To: eprints-tech at ecs.soton.ac.uk<mailto:eprints-tech at ecs.soton.ac.uk>
Subject: [EP-tech] Does 'can_clone' work correctly?

Hi,

Just wondering if anyone else can verify a problem I am having, (or doing wrong) on a 3.3.10 instance...

According to the documentation (https://wiki.eprints.org/w/Metadata), can_clone is a property that can be set in the field definitions, and is used quite liberally in the EPrints.pm : get_system_field_info sub
e.g.
{ name=>"datestamp", type=>"time", required=>0, import=>0,
              render_res=>"minute", render_style=>"short", can_clone=>0 },

       { name=>"lastmod", type=>"timestamp", required=>0, import=>0,
              render_res=>"minute", render_style=>"short", can_clone=>0, volatile=>1 },

       { name=>"status_changed", type=>"time", required=>0, import=>0,
              render_res=>"minute", render_style=>"short", can_clone=>0 },



to filter out data you don't want to copy across when cloning...

foreach my $field ( $self->{dataset}->get_fields )
       {
              next if( $field->get_property( "can_clone" ) );
              delete $data->{$field->get_name};
       }


Taking this a step further, I have altered the local repository eprint_fields.pl field definitions, to include the can_clone => 0 into a few test fields, but the data still gets cloned into the new record.
e.g.
{name => 'test_field_1',
 type => 'set',
 options => ['yes','no','pending'],
 can_clone => 0,
},

Can anyone confirm if it's not working correctly, or point me to what I'm doing wrong ?

Cheers

Matt





_____________________________________________________________

This email (including any attached files) is confidential and is for the intended recipient(s) only. If you received this email by mistake, please, as a courtesy, tell the sender, then delete this email.



The views and opinions are the originator's and do not necessarily reflect those of the University of Southern Queensland. Although all reasonable precautions were taken to ensure that this email contained no viruses at the time it was sent we accept no liability for any losses arising from its receipt.



The University of Southern Queensland is a registered provider of education with the Australian Government.

(CRICOS Institution Code QLD 00244B / NSW 02225M, TEQSA PRV12081 )



_____________________________________________________________

This email (including any attached files) is confidential and is for the intended recipient(s) only. If you received this email by mistake, please, as a courtesy, tell the sender, then delete this email.



The views and opinions are the originator's and do not necessarily reflect those of the University of Southern Queensland. Although all reasonable precautions were taken to ensure that this email contained no viruses at the time it was sent we accept no liability for any losses arising from its receipt.



The University of Southern Queensland is a registered provider of education with the Australian Government.

(CRICOS Institution Code QLD 00244B / NSW 02225M, TEQSA PRV12081 )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20170517/46897a8d/attachment-0001.html