User can submit view for assesment to the group where s/he has admin or tutor role

Hi Ruslan,

There was a brief discussion on that at http://mahara.org/interaction/forum/topic.php?id=2212

I'd favor this solution of yours: "allowing it only if there are other tutors or admins in the group (in which case user will not be able to assess own view despite the role"

Kristina

I have applied agreed scenario. Apart of that, own views will not be shown in the list of views submitted for assessment, unless user is the only member of the groups with view assessment permissions. (This is to allow last admin to release own view if other members with assessment permissions has been demoted to ordinary members after the view had been submitted).

Hi Ruslan & Kristina,

I don't think this is a bug. I'm not going to die in a ditch over it, but for what it's worth I'd vote to revert these patches altogether. They're adding more rules and complexity for very little gain. If a tutor gets past the 'really submit this view' confirmation screen, and submits a view to their own group mistakenly, what's the worst that can happen? They have to release their own view, which hardly seems a big deal.

But even if you think people are offended by the clutter of the submit form, I still think the rules should be simplified. It's just pretty odd that tutors *can't* submit a view when they're they only tutor, and *can* submit a view if there are other tutors in the group. If tutors are annoyed by the clutter of the submit form, they'll be annoyed regardless of how many tutors are in the group. If you really think it's important to restrict submit permission (and I don't) then surely it should be like the release permission, based purely on the user's role within the group, not on how many other users there are in the group with the same role.

Hi Richard and Ruslan,

If we look at this just from the generic view submission procedure, then it may seem too much to create the special case that a tutor can't assess his own submitted view. However, if you look at it from a peer assessment perspective, the rules that Ruslan implemented are beneficial because the owner of a view, despite his tutor role, cannot release his view during the assessment period and change things and then submit it again. The point of submitting views is that the owner cannot make changes (with certain limitations). That should also be in place for peer assessment.

One thing that I would change though (sorry for not writing earlier): The tutor should still see his submitted view in the list of all submitted views so that he is sure that it is there. It should just not have the "Release view" button for him.

So these rules assume that groups with >1 tutor are being used for peer assessment? I guess we can live with this hack in the short term if peer assessment groups are really important. But it really is just a workaround, and I think in the longer term a better way to do this would be to have a special group type for peer assessment, without a tutor role at all, in which ordinary members can submit their own views and release anyone else's. Otherwise in courses with real students and >1 tutor, we still have the problem of the tutors seeing the submit form.

>The tutor should still see his submitted view in the list of all
>submitted views so that he is sure that it is there. It should just not
>have the "Release view" button for him.

Will fix that as soon as we decide whether to rollback or not.

I partly agree with both of you: on one hand, as Kristina said, owner should not be able to submit a view for own assessment (and release own view), that was the initial reason why I submitted this bug. On the other hand, I agree with Richard that it adds some complexity and probably having a separate group for peer assessment is easier.

> I think in the longer term a better way to do this would
> be to have a special group type for peer assessment

Yes. That would definitely be better. But could we use Ruslan's solution as interim one?

Kristina, we won't put it in stable anyway, and the next release is a few months away now, so we have some time to decide on this. Personally I'd rather leave it out in the meantime on a separate feature branch where we can pull it in if we need it before 1.4. Maybe someone will want us to do peer assessment and provide funding to do it properly! (Probably unlikely).

Ruslan, if we did decide to go ahead with this rule I think one patch (25850d45) should be rewritten a bit. On My views and on the view page, as written it's going to run through all the user's course groups and count the tutors in each one with a separate query for each group. It'll be bad for users with a lot of groups (maybe not on your development machine, but when the db is over the network). It's also usually not really worth it, because 99% of the time you visit my views, or visit a view, it's not to submit the view. If there's no easy way around this, it might be better if we remove view submission from those pages altogether - submission can still happen from the group's page or perhaps from some new page.

So, shall I revert them then? Indeed, if anyone decide to proceed with this feature, one could cherry-pick my initial commits.

I'm confused, has this been reverted or not?

Yes, it has been reverted (9b3beda9c15). Sorry for not updating in the tracker.