Developers can't check checkboxes in comments created by other users
Summary
Developers don't have the write to modify comments posted by others, so they can't check checkbox posted by others.
Steps to reproduce
- Created a checkbox in a comment for something that needs to be done.
- Other people can't check the checkbox. (Since people work in team and multiple people can be assigned to an issue, they need to check checkboxes proposed by others.)
What is the expected correct behavior?
Since 9.2, multi assignment is here, so many people can check checkbox posted into comments for issues. This shouldn't be blocked!
This bug happens on GitLab.com
Activity
@oliviermilla Please can you explain how you use checkboxes in comments? I've heard of a number of users doing this.
Related issue:
Hello @markglenfletcher,
what happens is that we use issues as a back and forth conversation between product / development / QA teams. Any new spec that was either not mentionned when creating the issue or added later on is added as a comment with the list of specs as checkbox so everyone can follow the status of the devlopment.
We do this all around when NEW features are created. This is less used for other issues.
But still, having checkboxes being checkable by everyone with the right access on an issue/project makes a lot more sense since even now multiple people can be assigned to a task.
-
Thanks for the feedback. I've been seeing more and more users doing this. We only tend to use checkboxes in the issue description where they are natively supported (system notes for marking as completed and task list numbers in the issue list, etc).
It looks like you're using the task lists differently, not as an overall task list for the issue, but for a number of collaborative sub-tasks that need to be completed.
This is similar to @rdoursenaud's requirement in the above issue.
@victorwu Please can you take a look?
-
Yes, we indeed use issues more like a BaseCamp thread of conversation. This is actually very productive since it leaves everyone on the same ticket for conversation when discussing features and specs. It is also a very effective communicative tool with the great advantage of having the full information attached to the issue.
Thanks for the feedback.
Task lists are not intended to be used in comment boxes. (I think it is actually confusing that we support them currently.)
In particular, comments in GitLab are designed to be relatively static. There are there to reflect a conversation flow. So we recommend users continue the conversation by adding new comments, rather than changing old ones. Thus, it serves as a history of an ongoing conversation. Naturally, we do want to allow editing comments for fixing simple typos, making small tweaks, or for moderation use cases.
So as the conversation evolves, the description becomes the dynamic source of truth.
@oliviermilla : I would recommend that you can use the description to add these additional checkboxes to reflect new specs. In particular, you can easily update the description and then keep appending any new specs, so that people can go back and check them off. And then you can use the comment thread to let people know what changed, reference the ongoing changes in the description, etc. With discussion threads already introduced and more optimizations coming in 9.3 and beyond (https://gitlab.com/gitlab-org/gitlab-ce/issues/30299), you'll be able to track multiple conversations and even "resolve" ideas going forward.
-
OK thanks, I'll spread the word around. The only trouble so far with that approach is that people can sometimes take time editing the original issue and find themselves editing a since-deprecated issue (someone else edited it in the background). But no big deal there.
Glad to see that Gitlab is turning many of its features into multi-* (multi/sub groups, multi-git pipelines, multi-assigned users, sub-tasks...). This makes it all the more powerful.
In my opinion, having checklists and subtasks is confusing for the users who always hesitate between which approach to have depending on the sub tasks and the conversations that could spring around them. Checklist pros are that all the infos are on the same issue while sub-tasks spread the conversation over multiple issues.
I believe that if discussions from sub-tasks were brought back to the parent ticket as a sub-thread, we could get the best of both worlds and remove the use of checklists entirely.
My 2 cents,
Cheers.
Thank you @oliviermilla for providing the valuable feedback. We are working on related issues, to be shipped in 9.3, and hope to add others, like sub-issues and blocking issues in the future. Hopefully you will find that useful as well. Thanks!
