Create "Admin Assistant" authorizer role #132

Open
mhrivnak opened this Issue Mar 14, 2012 · 13 comments

2 participants

@mhrivnak
TireSwingSoftware member

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
TireSwingSoftware member

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
TireSwingSoftware member

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

@mhrivnak
TireSwingSoftware member

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 jc0n was assigned Mar 16, 2012
@jc0n
TireSwingSoftware member

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
TireSwingSoftware member
@jc0n
TireSwingSoftware member

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
TireSwingSoftware member

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

@jc0n
TireSwingSoftware member

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
TireSwingSoftware member

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
TireSwingSoftware member

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
TireSwingSoftware member

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

@jc0n
TireSwingSoftware member

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?

@mhrivnak
TireSwingSoftware member
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment