Fix EZP-24905 Role assignment limitations #397
Fix EZP-24905 Role assignment limitations #397
Conversation
* | ||
* @return \Symfony\Component\HttpFoundation\Response | ||
*/ | ||
public function assignRoleBySectionAction(Request $request, $roleId) |
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.
assignRoleBySection? I'd go for assingSectionLimitationToRole maybe...
edit: or this is a new feature? can you assing roles by section now?
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.
It's not new, and I would maybe call it assignRoleBySectionLimitation
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.
assignRoleBySectionLimitationAction
then, to stay in sync with other *Action methods.
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.
ok. nevermind. depends on how you read it. as i see you could ADD a section limitation to a Role and you could assign A role TO a group of users. With the Limitation suffix looks better anyway.
i read it as "assing this role to a section of users". thats what's looked weird to me.
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.
@crevillo I wouldn't say it like that. It's always about "assigning a role to user/group", whether the assignment is limited or not. The limitation is for the assignment, not for the role.
It should be probably PR made from |
+1 |
<option value="{{ section.id }}">{{ section.name }}</option> | ||
{% endfor %} | ||
</select> | ||
{# TODO: Section ID 3 is hardcoded below, it should be read from the select above. #} |
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.
For reviewers who don't know, this TODO is part of what's moved to a follow-up (to keep the JS heavy stuff separate)
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 have removed button's attribute as it won't be used. Section ID will be taken directly from select.
Modified to take roleservice simplification into account.
Guess I can't plus-one my own work, but let's say I strongly endorse it. |
ping @yannickroger / @dpobel |
+1 but this can not be merged until when implement the sub-tasks to add the behavior to the new buttons. |
Seems to have been replaced by #543. |
https://jira.ez.no/browse/EZP-24905
Description
Not working yet. The gist of
RoleServerSideView
is:_pickAssignee()
which is used when assigning a role without limitation; this is working._pickAssigneeLimitSubtree()
, used for assigning with limit on subtree. This fires a UDW for selecting subtree, whosecontentDiscoveredHandler
calls__pickAssigneeLimitSubtreeAssign()
. That function should fire a UDW for selecting users/groups to assign to, but this fails silently.data-role-assignment-section-id
. The button calls_pickAssigneeLimitSection()
which fires a UDW for selecting users/groups. The UDW opens, but when selecting something it fails with "TypeError: s is undefined oop-min.js:8:1932"Tasks
Fix loading of the second UDW when assigning by subtree limitation(moved to subtasks)Ensure that the "assign by section limitation"-button reads section ID from the dropdown(moved to subtasks)Fix oop-min.js error for section limitation UDW(moved to subtasks)Remove console.log debugging lines(moved to subtasks)Notes
It's new PR, but it's the same as it was in #383
I have messed that one rebasing it on master, so this PR is the clear one based on master