-
-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CRM-21380: Add setting to block activity types from sending assignee … #11222
Conversation
Just to flag that a change to the Settings screen should be accompanied by a change to the documentation. |
e9d940d
to
ac98337
Compare
edbac71
to
2d3f4b4
Compare
2d3f4b4
to
d236326
Compare
tagging as wip until a doc and a unit test is added. |
6f60757
to
95a718e
Compare
Docs is being added here - civicrm/civicrm-user-guide#240. Also added a unit test to check for this setting. I've removed |
$('#filter_activity_type_notification').toggle(); | ||
$('#filter_activity_type_notification-desc').toggle(); | ||
}); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This javascript is overly complicated and prone to failure, since the .toggle()
function is being used without any arguments passed in, which means it could get out-of-sync with the checkbox. I'm also not a fan of how it hides the element then immediately shows it again, causing a potential annoying flash on page load.
Why is it necessary to target two elements filter_activity_type_notification
and filter_activity_type_notification-desc
instead of using a wrapper around both?
The UI looks confusing in the screenshot. It's not clear what "Blocked Activity Types" means or that it's related to the checkbox above. It's also not clear whether the activity types listed in the left box or the right box are "blocked." I suggest the following changes:
|
Done all the suggested changes. The first commit of this PR actually contained the select2 widget as the element. It was changed to I've updated the element to select2 with the |
ed04cee
to
45995c1
Compare
45995c1
to
b5407aa
Compare
That screenshot is a bit extreme. I think the intention is to only block a few activity types. |
@@ -37,6 +37,7 @@ | |||
class CRM_Admin_Form_Preferences_Display extends CRM_Admin_Form_Preferences { | |||
public function preProcess() { | |||
CRM_Utils_System::setTitle(ts('Settings - Display Preferences')); | |||
$optionValues = CRM_Activity_BAO_Activity::buildOptions('activity_type_id', 'validate'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you want to pass the 'validate' context here because then labels won't be shown properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the changes as per the above comment. Also handled the false display of notification description text(both activity and case activity forms) for activity types selected in do not notify
setting. Thanks for the review @colemanw
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, missed to rebase before pushing the update which removed your commit. I've now included the js cleanup you did on this PR.
ba49604
to
e680ea4
Compare
templates/CRM/Case/Form/Activity.tpl
Outdated
CRM.buildCustomData( '{$customDataType}' ); | ||
{/if} | ||
{literal} | ||
var doNotNotifyAssigneeFor = ["{/literal}{'","'|implode:$doNotNotifyAssigneeFor}{literal}"]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think best practice is to use json_encode
whenever assigning smarty variables to js vars. E.g.
var doNotNotifyAssigneeFor = {/literal}{$doNotNotifyAssigneeFor|@json_encode}{literal};
I know there's lots of examples in tpl files where we don't do that but I've fixed quite a few bugs caused by improper escaping and edge cases that were solved by using json_encode
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated and tested the above json_encode assignment and it works fine 👍
Tested it out and all the JS is working as designed. The mail functionality comes with a unit test so I think we're good to go. |
@colemanw For the client who funded this, their requirement was that notifications are limited to a very few Activity Types - so the example may see 'extreme' but it is the actual use case this has been developed for |
CRM-21380: Add setting to block activity types from sending assignee …
…notification
Overview
"Notify Activity Assignee" setting manages whether to send emails to the assignees or not.
This PR provides extra configuration to block emails for certain activity types even if the main setting is checked.
Before
No way to block some activity types from sending email to assignees.
After
New setting available on
Display Preference
Page to disable notification for some activity types.Comments
As it adds a new setting, a menu rebuild is needed to test this.