Create "Admin Assistant" authorizer role

[mhrivnak]

The scope of this role is within an organization.

To have these permissions, a user must be associated with the given organization and have the org role named "Admin Assistant" within it.

• can create new users in their org
• for a user not assigned to an org and with 'pending' status, can assign that user to the actor's org and change user status to 'active'
• can assign users in own org to tasks and CurriculumEnrollments
• can edit status assignments for users in own org
• can view assignments for users in own org. this includes all current view methods in assignment_manager
• can edit own user info with same permissions as a Learner
• can view all Tasks, Curriculums, Events, Sessions, EventTemplates, SessionTemplates, etc.

[mhrivnak]

This may not be limited to an organization after all. Please await confirmation from Ryan before going down that path.

Previous quote from Ryan: Users in this role have the ability to manage registration and enrollment details on behalf of others. This is a common help-desk kind of permission set.

[mhrivnak]

If this is not limited to an org, then it will be implemented by creating a group named "Admin Assistants"

[mhrivnak]

Ryan confirmed that the scope is limited to an organization and all child orgs. So application of this role to a user will require that user to be a member of an org or parent org with the org role "Admin Assistant".

[jc0n]

for a user not assigned to an org and with 'pending' status, can assign that user to the actor's org and change user status to 'active'

Should this constraint apply to Organization Admin role as well?

[mhrivnak]

That would be a good idea.

On Fri, Mar 30, 2012 at 4:44 PM, John O'Connor
reply@reply.github.com
wrote:

for a user not assigned to an org and with 'pending' status, can assign that user to the actor's org and change user status to 'active'

Should this constraint apply to Organization Admin role as well?

---

Reply to this email directly or view it on GitHub:
#132 (comment)

[jc0n]

Do we want to allow any of the following?

• delete UserOrgRole objects (I'm also curious if this applies to Organization Admin)?
• create Tasks (if so, which types)
• create CurriculumEnrollments

can edit status assignments for users in own org

Just to clarify, this means edit the 'status' field of an Assignment object?

[jc0n]

The existing OrgRole is named "Precor Admin Asst". Should we stick with that or rename it to "Admin Assistant".

[jc0n]

can assign users in own org to tasks and CurriculumEnrollments

Regarding the enrollments, I am assuming that this implies create permission for CurriculumEnrollmentUserAssociation. However, there is no CurriculumEnrollmentUserAssociationManager and the current tests for enrollment assume that the role has create permission for CurriculumEnrollment and users are added when the enrollment is created in the create method of the CurriculumEnrollmentManager. As far as I can tell there is no way (currently), to add users to an existing enrollment using a manager. It also seems desirable to keep these two permissions separate in practice.

I am assuming that a new manager should be added for the CurriculumEnrollmentUserAssociation object and that this role will have permission to create said object and not CurriculumEnrollment.

[mhrivnak]

Do we want to allow any of the following?

delete UserOrgRole objects (I'm also curious if this applies to Organization Admin)?
create Tasks (if so, which types)
create CurriculumEnrollments

Nope.

Just to clarify, this means edit the 'status' field of an Assignment object?

Yep.

The existing OrgRole is named "Precor Admin Asst". Should we stick with that or rename it to "Admin Assistant".

Let's change to "Admin Assistant"

[mhrivnak]

I believe that if you simply use the ObjectManager.update method to add users to the CurriculumEnrollment.users property, the through-table model gets automatically created. The comment on the through model implies that it's not meant to necessarily be exposed with the remote API.

[jc0n]

Ah. That makes sense. I didn't really get much from the doc block.

[jc0n]

can view all Tasks, Curriculums, Events, Sessions, EventTemplates, SessionTemplates, etc.

What is the scope of 'all' here? Does this imply that the listed objects are exempt from the organization/role check?