Teachers. I mean who are they really?

[btbonval]

@stephskardal helped us clean up the CanCan Ability file.

There were some pieces that were super hard to read, notably in the teacher section.

Annotation-Studio/app/models/ability.rb

Lines 16 to 22 in 65e959c

	cannot :manage, Document do |tors|
	if tors.user.nil? # This has been driving me insane.
	false
	else
	tors.user.id == user.id
	end
	end

For now, we removed the ugly unreadable code. However, we should probably find out from the upstream project what the intended permissions for teachers is supposed to be.

[btbonval]

My guess is that a teacher act as the owner of any documents that the teacher's students make, likely decided by way of repertoire groups. But then, the code we removed doesn't even look at repertoire groups.

In fact, as far as we can tell, it's just a really elaborate way of saying the one liner a few lines below: a teacher can only manage the id's he/she owns.

In that sense the only difference between a teacher and student is that a student can only read documents in his/her group(s), while a teacher can read any document at all.

Since a student can arbitrarily add himself or herself to any group without restriction, the whole notion of using repertoire groups is security through obscurity (basically the worst thing you can do). Really not sure what they were going for here.

[AndrewMagliozzi]

Bryan, you are spot on.

In Annotation-Studio, teachers manage classes of students who are divided into groups to read documents together.

In Annotorious, I see no need to restrict permission to those managerial features to teachers only. Our users will all begin as read only but slowly we can add all of the features enjoyed by student and teacher roles alike.

Make sense?

On Jun 3, 2014, at 5:44 PM, Bryan Bonvallet notifications@github.com wrote:

My guess is that a teacher act as the owner of any documents that the teacher's students make, likely decided by way of repertoire groups. But then, the code we removed doesn't even look at repertoire groups.

In fact, as far as we can tell, it's just a really elaborate way of saying the one liner a few lines below: a teacher can only manage the id's he/she owns.

In that sense the only different between a teacher and student is that a student can only read documents in his/her group(s), while a teacher can read any document at all.

Since a student can arbitrarily add himself or herself to any group without restriction, the whole notion of using repertoire groups is security through obscurity (basically the worst thing you can do). Really not sure what they were going for here.

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

[btbonval]

Okay, teachers are the same as document owners for any documents created within their groups/classes. That is easy enough to implement and I'm about 75% sure that is not how Annotation-Studio works right now.

I'm not sure I understand what you want for Annotorious. I do understand the concept of starting at read-only. Can do! When you say "adding features", do you mean adding features in the sense of adding code to the backend, or adding features in the sense of adding permissions to an existing user through the web interface?

[btbonval]

The change to teacher/student during cleanup is part of the guest user pull request.

We should file a ticket upstream to verify whether teachers and students work as desired before submitting a pull request, or else our guest user pull request will remove features. I don't understand how the current CanCan code in AS could support teachers having any different privileges than students, but I also don't know all the Rails magic. We should at least check before potentially removing this feature in a PR.