Skip to content
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

dev/core#421 Fix issue where creating user driven message templates w… #12896

Merged
merged 1 commit into from
Oct 8, 2018

Conversation

seamuslee001
Copy link
Contributor

@seamuslee001 seamuslee001 commented Oct 5, 2018

…as requireing the ssystem workflow message template permission as well

Overview

This fixes a regression from #11974 which mean that creating any message template including a user driven message template required all 3 permissions when the intent was clearly they should be split up

Before

Creating a user driven message template requires all 3 permissions to work

After

Now only requires the 2 specifically related permissions as per the quickform

Technical Details

This changes the permissions on the entity.action but adds in specific checks in the create action to do the targeted permissions checks needed

ping @eileenmcnaughton @mickadoo @johntwyman @ajesamson

@civibot
Copy link

civibot bot commented Oct 5, 2018

(Standard links)

elseif (!CRM_Core_Permission::check('edit user-driven message templates')) {
throw new \Civi\API\Exception\UnauthorizedException(ts('Editing or creating user driven workflow messages requires edit user-driven message templates as well as edit message templates'));
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we move this permission check block down to BAO? Intent is to shift such checks and other manual codes down to CRUD fns and to make API more dependent on respective BAO fns.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@monishdeb i guess so, that would be the only way to make this apply to v3 and v4 right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly 😅

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re api vs BAO - I don't feel like we've really had those conversations & are still mostly in the api & in ad hoc other places - so we're not really being systematic yet - but this makes sense here

CRM_Core_Config::singleton()->userPermissionClass->permissions = array('edit message templates', 'edit system workflow message templates', 'edit user-driven message templates');
$this->callAPISuccess('MessageTemplate', 'create', ['id' => $userEntity['id'], 'msg_subject' => 'User template updated by system message permission', 'check_permissions' => TRUE]);
$this->callAPISuccess('MessageTemplate', 'create', ['id' => $entity['id'], 'msg_subject' => 'test msg permission subject', 'check_permissions' => TRUE]);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice :)

@@ -55,6 +55,11 @@ public function setUp() {
);
}

public function tareDown() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tare it down

@@ -1486,8 +1486,8 @@ public static function getEntityActionPermissions() {

$permissions['message_template'] = array(
'get' => array('access CiviCRM'),
'create' => array('edit message templates', 'edit user-driven message templates', 'edit system workflow message templates'),
'update' => array('edit message templates', 'edit user-driven message templates', 'edit system workflow message templates'),
'create' => array('edit message templates'),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would have 'worked' had the array structure been different - see the double array in this place. However, I can see that your version precise than this

      'default' => array(
        // At minimum the user needs one of the following. Finer-grained access is controlled by CRM_Case_BAO_Case::addSelectWhereClause
        array('access my cases and activities', 'access all cases and activities'),
      ),
    );

@@ -83,6 +83,27 @@ public static function setIsActive($id, $is_active) {
* @return object
*/
public static function add(&$params) {
// System Workflow Templates have a specific wodkflow_id in them but normal user end message templates don't
// If we have an id check to see if we are update, and need to check if original is a system workflow or not.
if (!empty($params['id']) && !empty($params['check_permissions'])) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So my understanding is that if they have ''edit message templates'' then we don't need to check the workflow id as that permission is more like 'either'

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eileenmcnaughton my understanding was that the idea was that it would have to be edit message templates + either system or user edit permissions. i.e. getting away from just having edit message templates.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ajesamson @guanhuan this was a Compucorp PR so comments very welcome

@seamuslee001 see #11974 - " This helps to further limit which of the templates a user can view and edit, while retaining exiting edit message templates permission for backward compability."

My understanding is that 'edit message templates' should work as it always has - to use more granular this should be removed & the more granular used instead

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@seamuslee001 What @eileenmcnaughton said is correct. It is not meant to be

edit message templates + either system workflow or user-driven permissions

The essence of leaving edit message templates permission is for backward compatibility. Users are notified on upgrade (as suggested by @colemanw due to some implementation complexity) of the new permissions. They are then expected; at their own discretion, to disable edit message templates while assigning either system workflow or user-driven message templates permission (or both) to users as applicable to their system.

cc @mickadoo

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep understand now, i'm working on an update just now, that should implement that concept as well.

@seamuslee001
Copy link
Contributor Author

ok @eileenmcnaughton @ajesamson @guanhuan etal my latest fix should prove that having just edit message templates permission is enough however the API will also accept one of the granular permissions + properly validate if just the granular permission is granted

@eileenmcnaughton
Copy link
Contributor

@seamuslee001 this is good to merge now - although it makes sense to merge to the rc

…as requireing the ssystem workflow message template permission as well

Wrap permission checking in the check_permissions param

Move Permission checking to BAO level from API

Allow for the fact that edit message templates permission should still be able to work on both sets of templates without the granular permissions. Also reduce duplication of code abit
@eileenmcnaughton
Copy link
Contributor

looks good

@seamuslee001
Copy link
Contributor Author

Test failures unrelated Merging as per the tag

@seamuslee001 seamuslee001 merged commit 585d646 into civicrm:5.7 Oct 8, 2018
@eileenmcnaughton eileenmcnaughton deleted the dev_core_421 branch October 17, 2018 19:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants