"automatic updating" permission

[photomedia]

After upgrading from version 1.7 to version 2.0, I see a new permission for "automatic updates". Is that permission only stored locally at the repository? Unlike the others, It's not sent/set within ORCID as well, right? What happens if someone gives permission for auto_updates, but doesn't give permission to update/modify ORCID record? The "automatic" wont work, right?

[photomedia]

To clarify, I'm asking about this:

orcid_support_advance/lib/lang/en/phrases/z_orcid_support_advance.xml

Line 103 in cc1c446

<epp:phrase id="Plugin/Screen/ManageOrcid:/activities/update_orcid_auto_update_select_text">Allow <epc:phrase ref="archive_name" /> to automatically update activities on your ORCID record</epp:phrase>

@wfyson, is this permission ever sent/synchronized with ORCID? Is that why it's not listed in the "Summary of granted permissions" at the top part of the "Manage ORCID Permissions" screen?
I'm having real difficulties/confusion with this. After the user has given permission to write/update the ORCID profile, why ask in a separate place for permission to do it "automatically" ?

[wfyson]

Hi @photomedia, this extra permission for auto-exporting doesn't get sent to ORCID, but has been pulled out as a separate permission as it does change the nature of the relationship between the repository and people's orcid.org profiles. As a lot of repositories already have the ORCID Advance plugin in place with connected accounts already, I think there was some concern from repository administrators about changing how the export works without checking in with users to see if they're happy for that to take place.

As it doesn't get sent to ORCID it ends up being stored in the new orcid_log dataset, which is also used to check the state over the course of the OAuth request. This mostly takes place at

orcid_support_advance/cgi/orcid/authenticate

Lines 36 to 55 in cc1c446

	if( defined( $authcode ) && defined( $state ) )
	{
	# check the response against the orcid_log record using the returned state
	my $sth = $db->prepare_select( "SELECT id FROM orcid_log WHERE user =".$db->quote_int( $current_user->get_value( "userid" ) )." AND state =".$db->quote_value( $state ) );
	my $success = $sth->execute;
	if( $success ne "1" )
	{
	$db->save_user_message($current_user->get_value( "userid" ),
	"error",
	$repo->html_phrase( "Plugin/Screen/AuthenticateOrcid:unexpected_state" )
	);
	$repo->redirect( $repo->config( 'userhome' ) );
	exit;
	}
	# get the log object, get any local permissions we might need... and then remove the log object
	my $log_ds = $repo->dataset( "orcid_log" );
	my $log = $log_ds->dataobj( $sth->fetchrow_arrayref->[0] );
	my $auto_update = $log->value( "auto_update" );

It's also true that even if the auto-export field is set, if the generic "update/modify" permission hasn't been given then the export wouldn't take place, as per the check at

orcid_support_advance/lib/plugins/EPrints/ORCID/Exporter.pm

Line 43 in cc1c446

if( defined $user && EPrints::ORCID::AdvanceUtils::check_permission( $user, "/activities/update" ) && $user->is_set( "orcid_auto_update" ) && $user->value( "orcid_auto_update" ) eq "TRUE" )

I think ideally however that permission shouldn't be allowed to be set if the general update/modify hasn't been set - a bit of JavaScript to make the form a bit clearer is probably needed here!

Also as the auto export permission isn't one sent to ORCID, it could just be a field/flag that just appears on the user profile. I've think I added it to the Manage Permissions screen as it felt like it made sense at the time, and hopefully is the best place for it for new users connecting their accounts (and of course if it's not a distinction that needs to be made, it could just be set to true by default behind the scenes as it were).

[photomedia]

Thank you, @wfyson for these explanations.
I think that there is a lot lost in terms of comprehensibility by the end user when we introduce an option that is not synched with ORCID into the "Manage ORCID Permissions" screen.
I understand that some administrators may want to include this option to update "automatically" within their repositories, but this is not, strictly speaking an "ORCID permission", it is rather an ORCID setting or option within the repository. I think that if this option is given to users, it should be separated out on the interface clearly as an option that is not sent/synched to ORCID, with some additional greying/out on the ACTUAL permission setting.
Let's focus on this part: "if it's not a distinction that needs to be made, it could just be set to true by default behind the scenes as it were". I agree, how can we make it easier on the administrators to choose to keep this option as an administrator option, not controlled by the user? How would an administrator remove this as a "permission" set by the user, but nevertheless retain the "global" repository-wide option to perform these ORCID updates "automatically"?

[photomedia]

@wfyson I've been trying to figure out what I would need to do to remove the
"Allow REPONAME to automatically update activities on your ORCID record" from the manage orcid permissions screen in the least destructive most sustainable way, keeping the rest of the code working, and I can't figure it out!
I would want this "permission/option" to remain hidden from users, with an assumption/default of allowing "automatic" updates.
It's simple enough to add a new variable in cfg.d/z_orcid_advance.pl but I don't know how many other files I would have to touch/modify to make this work.
Any help on this would be greatly appreciated!

[wfyson]

Hi @photomedia - just to check am I right in thinking you want the field completely hidden and essentially always turned on for all users? If so I think the easiest way of doing this may be to:

1. Override the ManageOrcid.pm screen so that either "render_local_permissions" doesn't call render_permission_sub_field OR update render_permission_sub_field so that it returns unded instantly.
2. Update ORCID/Exporter.pm line 43 (mentioned above in my earlier comment), so that the orcid_auto_update field isn't checked OR set the orcid_auto_update field so it just defaults to TRUE for all users (i.e. via user fields automatic or user field defaults)

Looking at this again now I see I haven't handled the auto-update sub field of the update permission all that well. Really it should act in the same fashion as the other permissions and then we could just have set it's user_edit property to 0 - maybe there was a reason why I didn't do that, but I can't see it right now! Something for a future update!

[photomedia]

"just to check am I right in thinking you want the field completely hidden and essentially always turned on for all users?"
Yes, that's what I need.

[photomedia]

OK, here is what I did to have the field hidden and always turned on.
I added this option in z_orcid_support_advance.pl:

# Disable permission subfields i.e., "automatic updating", as a visible permission
$c->{orcid_support_advance}->{disable_permission_sub_fields} = 1

I then surrounded this line:

orcid_support_advance/lib/plugins/EPrints/Plugin/Screen/ManageOrcid.pm

Line 369 in dd18186

$local_perms_div->appendChild( $self->render_permission_sub_field( $repo, $user, $permission ) );

with the following condition (checking for the variable):
if(!(((defined $repo->config( 'orcid_support_advance', 'disable_permission_sub_fields' ))) && ($repo->config( 'orcid_support_advance', 'disable_permission_sub_fields' ) == 1)))

Lastly, I set orcid_auto_update to TRUE in user_fields_automatic.pl:

if( !$user->is_set( "orcid_auto_update" ) )
	{
		$user->set_value( "orcid_auto_update", "TRUE" );
	}

[wfyson]

That all looks good to me - does it work ok? In a future update I'll try and make these both configurable flags that can just be turned on or off.

[photomedia]

Yes, I confirm that it is working on my repo. The additional "sub option" of automatic updates doesn't show when the disable flag is set to 1, and the connect/authenticate is still working as before. Thanks for your help with this! If this could be made into a configurable flag in the plugin for everyone, that would be most excellent.