add support for roles and workflow

[tssheth]

Allow staff to add grades, but they shouldn't be presented to the student (nor recorded in student state) until an instructor has approved them.

I think this can be done by adding an adding an "approved" field that can only be changed by an instructor. Grades are not returned to the student unless the approved field is set to true.

An enhancement would to have this be an optional feature, although I don't know where the option could be set -- perhaps when the problem is authored?

(see jazkarta#20)

[chrisrossi]

I've taken an initial stab at this one. I'll hold off on closing this issue until I've gotten some feedback.

[pdpinch]

@carsongee This is lgood enough for the residential release (I know, we're past the point of decision, but I thought I'd memorialize it).

@chrisrossi I do have a scope-creep question: we're using the staff and instructor roles to manage access. However, if we move to edX the staff role is overloaded. What would be involved in creating a new "grader" role? I presume that would be an edx-platform change and not an XBlock change, but I wanted to check.

[chrisrossi]

On Mon, Aug 25, 2014 at 9:19 AM, Peter Pinch [email protected]
wrote:

@carsongee https://github.com/carsongee This is lgood enough for the
residential release (I know, we're past the point of decision, but I
thought I'd memorialize it).

@chrisrossi https://github.com/chrisrossi I do have a scope-creep
question: we're using the staff and instructor roles to manage access.
However, if we move to edX the staff role is overloaded. What would be
involved in creating a new "grader" role? I presume that would be an
edx-platform change and not an XBlock change, but I wanted to check.

It's hard to say without digging into it and looking, but your intuition is
probably correct, that we're at the mercy of the platform and would need
modify that. Possibly, you could make a case for a more generic
roles/permissions system that doesn't presuppose how it will be used within
a course. Different features would require permissions, rather than roles.
Roles would be granted permissions. Grading would then be a permission
that is granted or not to a particular role or roles in the course. Taking
a look at how Pyramid does it, might be helpful.

Chris

[carsongee]

Is it not sufficient to use the course_staff vs instructor difference, or is giving course_staff too much privilege? If we do need a special role, I don't think it would be that much to add it as I've had a fair bit of experience in that part of the code base (just an extra Role class in https://github.com/edx/edx-platform/blob/master/common/djangoapps/student/roles.py and some fiddling with the instructor dashboard. In addition to the staff/instructor roles, there are also several forum roles that I think use the same "Roles" style for the course and underneath it all it is just using stock Django groups with some course identifying abstractions.

[pdpinch]

Staff and Instructor roles are totally fine residentially.

But in the MOOC context, the plan is to hire a bunch of graders-by-the-hour and we don't really want to give them permission to make changes to course content (in studio). So an additional role would be desirable.

All speculative for now. You've both answered my question about scope.

• Peter

On Aug 25, 2014, at 10:05 AM, Carson Gee [email protected] wrote:

Is it not sufficient to use the course_staff vs instructor difference, or is giving course_staff too much privilege? If we do need a special role, I don't think it would be that much to add it as I've had a fair bit of experience in that part of the code base (just an extra Role class in https://github.com/edx/edx-platform/blob/master/common/djangoapps/student/roles.py and some fiddling with the instructor dashboard. In addition to the staff/instructor roles, there are also several forum roles that I think use the same "Roles" style for the course and underneath it all it is just using stock Django groups with some course identifying abstractions.

—
Reply to this email directly or view it on GitHub.

[pdpinch]

This will be addressed in 0.4.0