Reduce the number of options to choose from under notifications

nef · August 17, 2018, 2:27pm

Hi,
Is it in any way possible to reduce the number of options to choose from given to the registered readers when they go to Notifications under their profile. For instance I would like to remove the possibiblity of choosing the Submission Events. Hope its possible without doing any code work.
Best regards
Niels Erik

ajnyga · August 20, 2018, 2:23pm

I do not know any other way than by editing this template: https://github.com/pkp/pkp-lib/blob/master/templates/user/notificationSettingsForm.tpl

Or you could do a plugin that hooks to the templatemanager, checks if that template is being processed and then maybe uses a smarty filter to disable the checkboxes.

nef · August 21, 2018, 8:06am

Thank you. I really hope that the default settings will be changed in the near future. A lot of our users have wondered why they receive so many notifications

ajnyga · August 21, 2018, 11:31am

I think what we need is an easy unsubscribe function to the notification emails. This has been under discussion and now that @NateWr added the possibility to opt-out of those emails, I think an unsusbscribe link should be fairly easy to add for the next release of OJS.

We also had a lot of users asking about the notifications when we introduced OJS3. It seems that OJS3 sends a lot more of those compared to OJS2. But now that journals can choose if they want to send a notification it is a lot better and probably the users are getting accustomed to the notifications as well.

Changing the default of what the system does at the moment is a bit difficult, because probably it just checks if the user has opted out. If not, it sends the email. So for most users there is no actual selection in the database.

You could of course add an opt-out selection straight to the database for all users, but then those who actually want to see the notifications would not anymore. For new users it is not a problem because they opt in (or out) when they register.

nef · August 22, 2018, 8:31am

Apart from that it doesn’t always seems to work. I’ve just enabled the submission event “A new article, “Title,” has been submitted.” I’m registered as Reader but I don’t receive any messages after an author uploaded an article to the journal. That must be an error.
Regards
Niels Erik

ajnyga · August 22, 2018, 9:37am

I think it is expected behaviour. Only editors and the authors themselves would see that notification when enabled.

Being a reader an enabling that option would not mean that you would see notifications for all submitted articles.

nef · August 22, 2018, 10:01am

But why then show the option for Readers? At least some information should tell that a Reader can’t get access to that service.

ajnyga · August 22, 2018, 10:07am

yeah, I guess the options there could be filtered depending on the roles the user has. @NateWr?

NateWr · August 22, 2018, 10:21am

Should be. Can you test to see if they’re not and file an issue if not?

ajnyga · August 22, 2018, 10:30am

The user that has the reader role, does the same user have other roles in other journals in the same installation?

nef · August 22, 2018, 11:20am

I’ve just made a test with a user having only the reader role in one journal, and the person has the same options

ajnyga · August 22, 2018, 12:02pm

so @NateWr thinking of changing this function here: https://github.com/pkp/pkp-lib/blob/master/classes/notification/form/PKPNotificationSettingsForm.inc.php#L79

So that the code adds notification.type.public category to the array if the user has some role in the context, and adds notification.type.submissions and notification.type.reviewing categories if that the user has other roles besides reader in the context. How does that sound?

So for users with not roles in the context, nothing is being listed there?

Edit: something like this:

	public function getNotificationSettingCategories() {
		$request = Application::getRequest();
		$context = $request->getContext();
		$contextId = $context ? $context->getId() : CONTEXT_ID_NONE;
		$user = $request->getUser();

		$notificationSettingCategories = array();

		if ($user->hasRole(array(ROLE_ID_MANAGER, ROLE_ID_SUB_EDITOR, ROLE_ID_ASSISTANT, ROLE_ID_REVIEWER, ROLE_ID_AUTHOR, ROLE_ID_READER), $contextId)){
			$notificationSettingCategories[] = array('categoryKey' => 'notification.type.public',
					'settings' => array(
						NOTIFICATION_TYPE_NEW_ANNOUNCEMENT,
					)
			);
		}

		if ($user->hasRole(array(ROLE_ID_MANAGER, ROLE_ID_SUB_EDITOR, ROLE_ID_ASSISTANT, ROLE_ID_REVIEWER, ROLE_ID_AUTHOR), $contextId)){
			$notificationSettingCategories[] = array('categoryKey' => 'notification.type.submissions',
					'settings' => array(
						NOTIFICATION_TYPE_SUBMISSION_SUBMITTED,
						NOTIFICATION_TYPE_METADATA_MODIFIED,
						NOTIFICATION_TYPE_NEW_QUERY,
						NOTIFICATION_TYPE_QUERY_ACTIVITY,
					)
			);
			$notificationSettingCategories[] = array('categoryKey' => 'notification.type.reviewing',
					'settings' => array(
						NOTIFICATION_TYPE_REVIEWER_COMMENT,
					)
			);
		}

		return $notificationSettingCategories;

	}

NateWr · August 22, 2018, 2:33pm

I’d rather handle that logic in the template itself. Calling $user->hasRole() will result in an extra DB call, and it’s better if DB access is kept out of helper methods like that. It makes it more reusable if we ever want to call it elsewhere.

So I think you can do the user role checks and skip the appropriate categories in this template:

github.com

pkp/pkp-lib/blob/main/templates/user/notificationSettingsForm.tpl#L39-L58


				{assign var="settingName" value=$notificationSettings.$settingId.settingName}
				{assign var="emailSettingName" value=$notificationSettings.$settingId.emailSettingName}
				{capture assign="settingKey"}{translate key=$notificationSettings.$settingId.settingKey title="common.title"|translate}{/capture}

				{fbvFormSection title=$settingKey list=true translate=false}
					{if $settingId|in_array:$blockedNotifications}
						{assign var="checked" value="0"}
					{else}
						{assign var="checked" value="1"}
					{/if}
					{if $settingId|in_array:$emailSettings}
						{assign var="emailChecked" value="1"}
					{else}
						{assign var="emailChecked" value="0"}
					{/if}
					{fbvElement type="checkbox" id=$settingName checked=$checked label="notification.allow"}
					{fbvElement type="checkbox" id=$emailSettingName checked=$emailChecked label="notification.email"}
				{/fbvFormSection}
			{/foreach}
		{/foreach}

If you do this, can you file an issue first? It helps for the record if we have PRs that reference issue numbers.

ajnyga · August 22, 2018, 2:41pm

sure, just checking if the logic described above is ok?

NateWr · August 22, 2018, 3:33pm

I would have to take a closer look at it. Off-hand:

I’m not sure we should send a new submission notification to anyone but journal manager (does it include details that can compromise blinding?).
New announcements probably shouldn’t require any role.
Metadata modified… I’d have to look at this more closely, to work out the logic around who receives this email? Who should? This intersects some with Selectively permit author metadata changes after submission · Issue #3758 · pkp/pkp-lib · GitHub and the question of who should edit and, if it’s locked down, then who actually needs an email?

nef · August 23, 2018, 7:56am

Hi,
If you by the formulation “New announcements probably shouldn’t require any role” mean that all the options should be shown, I think that there, at least, should be some information about which options are available for who. And please don’t choose some as default, just keep the options open.
Best
Niels Erik

NateWr · August 23, 2018, 8:42am

In this case, I was speaking about an email notification that goes out when a new announcement is made. Anyone should be able to subscribe or unsubscribe to this email notification, regardless of their role.

ajnyga · August 23, 2018, 8:56am

I can not see how that would work.

The option is “Do not send me an email for these types of notifications.”. If we have a user without any roles and having that unchecked means that the context will send her email notifications, it would mean that she has to disable that setting from every context in that installation, which does not make sense?

I think the way it works now is that if you have any role in a context and the option is disabled, you get the email?

NateWr · August 23, 2018, 9:31am

I’m not suggesting we change the logic around who is sent the email. I’m just saying you can get rid of the conditional determining what settings to show a user:

		if ($user->hasRole(array(ROLE_ID_MANAGER, ROLE_ID_SUB_EDITOR, ROLE_ID_ASSISTANT, ROLE_ID_REVIEWER, ROLE_ID_AUTHOR, ROLE_ID_READER), $contextId)){
			$notificationSettingCategories[] = array('categoryKey' => 'notification.type.public',
					'settings' => array(
						NOTIFICATION_TYPE_NEW_ANNOUNCEMENT,
					)
			);
		}

If they are accessing the profile page in the context, we should be able to assume they have a role there.

ajnyga · August 23, 2018, 9:32am

Technically you can access your profile page from within any context in the site regardless if you have a role there, I think?

Edit: just checked, yes, you do not need a role to access a profile page from within a context. Because all of those notification emails are conditional to whether you have a role, it would make sense to hide all the selections if the user has no roles?