Create Serv Dealer Admin authorizer role

[mhrivnak]

The scope of this role may be within an organization. Ryan will confirm.

Quote from Ryan: Users in this role have the ability to manage registration and enrollment details on behalf of others, as well as create and assign tasks for organization members. They can view user achievement and credential status.
These are the people concerned with ensuring individual learners in partner organizations are being assigned
training and completing it.

• can create and edit all kinds of Task
• can create and edit TaskBundles
• can create Assignments
• can edit Assignment status
• can create users
• can import users via CSV
• can view all Tasks, TaskBundles, Curriculums, CurriculumEnrollments, Event/Session objects, etc.
• can view Achievements and Credentials, including user associations

[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 "Serv Dealer Admin".

[jc0n]

can view all Tasks, TaskBundles, Curriculums, CurriculumEnrollments, Event/Session objects, etc.

Similar question as in #132, What is the scope of 'all' here? Does this imply that the listed objects are exempt from the organization/role check?

[mhrivnak]

All means actually all. These objects are exempt from the org check for
this role.
On Mar 31, 2012 5:12 PM, "John O'Connor" <
reply@reply.github.com>
wrote:

can view all Tasks, TaskBundles, Curriculums, CurriculumEnrollments,
Event/Session objects, etc.

Similar question as in #132, What is the scope of 'all' here? Does this
imply that the listed objects are exempt from the organization/role check?

---

Reply to this email directly or view it on GitHub:

#133 (comment)

[jc0n]

All means actually all. These objects are exempt from the org check for
this role.

Got it.

can create and edit all kinds of Task

But we still want to ensure that created Tasks are only for the user's organization(s)?

[mhrivnak]

Yes. The idea is that you could assign a student to some other org's task.
On Mar 31, 2012 6:21 PM, "John O'Connor" <
reply@reply.github.com>
wrote:

All means actually all. These objects are exempt from the org check for
this role.

Got it.

can create and edit all kinds of Task

But we still want to ensure that created Tasks are only for the user's
organization(s)?

---

Reply to this email directly or view it on GitHub:

#133 (comment)

[mhrivnak]

When trying to create a user in my own org, I get:

permission denied for the following attributes: ('organizations'), on the User model

I strongly suspect this is because the 'organizations' attribute is in optional_parameters and is being set directly by "Setter", which checks update permissions. The solution is probably to have UserManager.create manually set the organizations instead of letting Setter do it.

[mhrivnak]

Also need to read names and ids of all OrgRoles.

OrgRoleManager'>.get_filtered[<AuthToken: b734d6cf12da4fc3be5af081771118ab>, {}, [u'name']] = {'status': 'OK', 'value': []}

[jc0n]

I strongly suspect this is because the 'organizations' attribute is in optional_parameters and is being set directly by "Setter", which checks update permissions. The solution is probably to have UserManager.create manually set the organizations instead of letting Setter do it.

What do you think about adding a parameter to Setter, which does what censored in Getter does -- just disable the authorizer. Then we can still leverage not having to deal with individual properties there.

[mhrivnak]

Sounds like a great idea.