Problem/Motivation
There is a chance I have my site mis configured.
I would like the anonymous (public) to be able to see boards so have granted "Access Burndown Board" to anonymous.
I do not want them to be able to alter the tasks on the board so I set these all to authenticated only.
- Edit Task entities
- Edit any {project name} entiities
- Edit own {project name} entities
- Modify Tasks in a Sprint
The problem is that if I go to the board as a user who is not logged in I can drag tasks around to other order or swim lanes and they changes get made to the task. As far as I can tell this is an incorrect escalation of privileges. A use that can not edit tasks, should not be able to alter the swimlane or weight of an item on the board.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork burndown-3591854
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
jeremylichtman commentedI think there's two related issues here:
I'll take a look today. It might make sense to add a new permission for "Can drag items on board".
Comment #3
jeremylichtman commentedComment #4
jeremylichtman commentedThere actually is a permission 'reorder burndown backlog'.
I have to make a mod to ensure that is respected by the AJAX endpoint.
Will look into how we can not load the js for users that shouldn't have that permission too.
Comment #5
jeremylichtman commentedI've created a MR here: https://git.drupalcode.org/project/burndown/-/merge_requests/25
@swirt Do you want to test this out?
It updates the permission for the AJAX endpoint to be the correct (already existing) one, and also only adds in the reordering js library if the user meets that permission.
I think this would allow you to make the board itself viewable, and then simply not grant the 'reorder burndown backlog' perm to anonymous users.
Comment #6
swirtI can test this out later tonight. Does 're-order' mean from one status/swim lane to another, or is that about priority (dragging top to bottom)?
Comment #7
swirtReorder the backlog sounds like adulting the weight/priority. Changing status/swimlane seems more like altering a property of the task so I expected that would be tied directly to the task edit perm..
Comment #8
jeremylichtman commentedIt's the same endpoint for everything. The board sends over a list of which items are in each column, along with their sort order.
Comment #9
swirtI left a note in the PR but since they are not using the issue fork they are not updating this issue.
I tried the patch, but I think it needs to have services.yml update to include "- '@current_user'" because it is creating this error.
Comment #10
jeremylichtman commentedI pushed a fix. The controller had both a __construct and create method for some reason, and they were interfering with each other.
Comment #11
jeremylichtman commented@swirt once this is okay on your end, I will merge and push a tag with this and the previous fix.
Comment #12
swirtI will test this out this morning.
Comment #13
swirtI left a note on the PR. This recent approach fails with an error which is caused by the class not having a constructor. the create() is not a replacement for __construct(), it is the thing that feeds the __construct().
Comment #14
swirtComment #15
jeremylichtman commentedActually, I just forgot to commit the final line of the create method (which returns the instance). [facepalm]
Comment #16
swirtI am seeing a loss of styling when I do not have permission to change order on the board. (see comment on MR)
Comment #17
jeremylichtman commentedI've added a new library for the unsortable boards, that only contains the css.
I think this should resolve the styling issue for the most part.
One thing that may still be a problem is opening up task details. If I recall correctly, there's some js involved, and they open as a form in a popup. We may need to build some other sort of interaction for users who don't have access.
Comment #18
swirtVisually it is working so that part is resolved. The dragging and dropping is prevented, so that is great.
As you mentioned, the controls are still on the cards though.
All of these should probably be bound to the edit perms.
Comment #19
jeremylichtman commentedMind adding some screen snaps for me?
I will work on this over the weekend.
Comment #20
swirtI just added a screen cap to the merge request. https://git.drupalcode.org/project/burndown/-/merge_requests/25#note_104...
Comment #21
jeremylichtman commentedI've added checks for permissions to the various links on the task card.
Also added a new permission "send tasks to backlog", and updated the API endpoint accordingly.
I think this should cover most scenarios, although wouldn't be surprised if something else comes up. It wasn't a use-case I had in mind 6 years ago.
Comment #22
swirtSorry for the delay. I've been away. I tried out the latest updates to the MR using this as the patch
https://git.drupalcode.org/project/burndown/-/merge_requests/25.diff
As an anon user, I am no longer able to re-order anything on the board. However I am still able to click the "Send task to backlock" arrow icon and send see it removed from the board. It hits the API at `/burndown/api/board/send_to_backlog/{task ID}` which gives a "success response that lets it through.
I'd like to work on this, but the branch you are working on is in the origin repo and not the issue fork do I don't have perms to edit. I am going to take a try at moving your code to the issue fork.
Comment #24
swirtOk, disregard what I said about the perms not working. I think composer was hanging on to the previous version of the patch. This seems to be working.
Though I am seeing a new deprecation error that I was not seeing before applying this patch.
"Deprecated: burndown_allowed_estimate_values(): Optional parameter $entity declared before required parameter $cacheable is implicitly treated as a required parameter in /var/www/html/web/modules/contrib/burndown/burndown.module on line 458"
I'll try to get that resolved now that this PR !27 exists on the Issue fork.
Comment #25
swirtNice work on this @jeremylichtman.
https://git.drupalcode.org/project/burndown/-/merge_requests/27 is tested and working great.
Comment #27
jeremylichtman commentedReleased on 1.0.58.