Peer assessor can delete another peers assessment

Bug #1859355 reported by Robert Lyon on 2020-01-12
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mahara
Status tracked in 20.04
18.10
High
Unassigned
19.04
High
Unassigned
19.10
High
Unassigned
20.04
High
Unassigned

Bug Description

When we have the following setup:

1) User A creates Page One and adds
- a peer assessment block
- a sign-off block

2) User A shares Page One to
- User B as 'peer'
- User C as 'peer'
- User D as 'no special role'

3) Login as User B and add an assessment to Page One

4) Login as User C and view Page One
*** problem ***
 - you shouldn't be able to delete the peer assessment of User B

This is also a problem when 'sign-off' block is not present

Robert Lyon (robertl-9) wrote :

The manual mentions:

"If the peer assessment block is used in conjunction with the sign-off block, the portfolio author must sign off the page before anybody other than themselves and the peer assessor can see published peer assessments."

So that is the way it should be working - but currently isn't

Robert Lyon (robertl-9) wrote :
information type: Private Security → Public
Robert Lyon (robertl-9) wrote :

Ok, I think I have worked out what is going on.

When peer assessment / sign-off was designed we had (as per the manual)

"If the peer assessment block is used in conjunction with the sign-off block, the portfolio author must sign off the page before anybody other than themselves and the peer assessor can see published peer assessments."

And the code handled that accordingly.

But then came Bug 1835321 - https://bugs.launchpad.net/mahara/+bug/1835321 - which was based on a request from WR 315075

So now peer assessments, once published, are visible before a page is signed off

This has now created this bug report where a user can delete a fellow peer's assessment

So is the note in the manual the correct way it should work for core versions of Mahara, and the change for WR 315075 just be a customisation for that client?
- therefore we need to revert the fix (bug 1835321) in core and make a custom fix for the client for bug 1859355?

Or is the manual wrong?
- therefore we need to fix up bug 1859355 in core and update the manual

The manual would be wrong in this case. :-( Nothing to revert.

Robert Lyon (robertl-9) on 2020-01-13
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers