Allow Users to Edit Issues
under review
O
Oliver Shilling
Let users edit issues after they’ve been created. Right now, once an issue is submitted, it’s locked in. This can lead to incorrect details, vague titles, and issues being assigned to the wrong person. Giving users the ability to edit would help keep reports accurate and useful.
Feature Overview:
- Let users update issue details after submission.
- Changes could include:
- Editing the issue title.
- Changing the priority level.
- Assigning the issue to a different person.
- Switching the issue type (e.g., bug → feature request).
- Revising the issue description.
Use Case:
- Users often submit issues with vague or incorrect titles, making it hard to track and organize them.
- Sometimes, an issue is misclassified (e.g., reported as a bug when it’s really a feature request).
- Teams may need to update priorities as new information comes in.
- Assignments may need to be changed if the wrong person is tagged.
Log In
Gary Gaspar
under review
Joe Scanlon
Merged in a post:
Editable Titles
Adam Collison
PLEASE allow us to edit the title of an item when its created! often users leave really vague titles and its impossible to coordinate activity once this happens.
We want to be able to edit titles after created to something more meaningful
Yellow Teapot
Yes please. These are crucial features.
Joe Scanlon
Merged in a post:
Please make story titles editable
Adam Collison
Sometimes customers use the most random names in the title and we have no way of easily keeping track of which issues relate to which.
Ideally as an admin clicking the story title would display a text area where we can update the title.
Joe Scanlon
Merged in a post:
Edit feedback Title
Elliott Mangham
Editing the titles would be super helpful, since our clients generally just use uninformative titles like "bug" and "another"... We'd love to rename them with our more useful naming conventions.
Joe Scanlon
Merged in a post:
Ability to edit feedback
Y
Ying
Ability to edit feedback descriptions and types etc.
For example, the user reports bug feedback, but it's actually a feature request. so I would like to be able to edit that feedback
Distinction
Editing the feedback type (bug, enhancement, etc.) would certainly be useful.
Having that also feed through to the integrated system (i.e. BitBucket) would also be needed though.
Adeline Deschamps
On our side, we change the title of the issue within our Project management tool. If this new title could be synced back to Marker.io, it'd be very useful as well
Gary Gaspar
Adeline Deschamps: How about the challenge of the reporter not recognising their original title? Would you like your reporter to see the updated title? or the original one? or both?
Adeline Deschamps
Gary Gaspar: As Elliot mentioned, the title are hardly ever informative so we make sure they are when they land in our Project management tool (Jira in our case). if the title was informative, we simply make it consistent with our naming convention > the feedback is still recognisable then. On our side, the reporter almost never update the title. So the latest title in Jira can be used everywhere
Gary Gaspar
Adeline Deschamps: that makes sense! Do you think there is a use case where you'd want the original title to stay in Marker, and another title in Jira?
Here is the use case I'm thinking:
- Reporter sends "the contact button does not work"
- Dev sees it in Jira and identifies that it's a back-end issue and renames jira issue to: "Fix API route for contact object"
If the reporter sees the new title, he might be super confused, right? Do you think this is a legit use case? Or that might not match reality?
Adeline Deschamps
Gary Gaspar For us, these would become subtasks of the initial issue so no problem about this. (but of course, this is our reality, might not be applicable for all :) )
Elliott Mangham
Gary Gaspar: I'm with Adeline Deschamps on this, I feel that whilst the client may not recognize it by title, that's what they should see so that it's consistent. That said, perhaps there should be a log, perhaps in the comments section in Marker, that says:
X renamed this ticket to "Fix API route for contact object" on D/M/Y.
Then everybody can be kept on track. Hope this helps!
Gary Gaspar
Elliott Mangham: that's a great point! Maybe it does not really matter that the title of the feedback changed if it becomes more accurate.
And better yet, we can maybe put a log there like this for example
cc Adeline Deschamps
Elliott Mangham
Gary Gaspar: This would be PERFECT and so useful! Especially with database syncing.
That said, I personally hope that Marker can become more independent with no third-party connections needed and better email triggers. So I can just rely on logging into Marker to view my feedback tasks and feel assured I'll be emailed (even if it's a digest) when things come in. (I've upvoted the other feature requests).
Gary Gaspar
Elliott Mangham I like this idea! How would see that play with your integration? Typically, if you edit the feedback title in Marker.io, do you want the issue title in your project management to update as well?
Lauren Gray
Gary Gaspar: I'll answer this one! Yes, if I change the title in MARKER I would like the title to change in my synced project (we use ClickUp). But if I change the title in the EXTERNAL program I would personally prefer that
not
sync (in contrast to the two-way sync proponents on this forum).Lauren Gray
Upon further consideration, I'd be OK with a two-way sync or a no-way sync for this, if either meant the option to change the task name in Marker would be released sooner. We get submissions where the task title has a whole Loom URL in it or is something useless like "White space" (consider that they're referring to a very specific space on a single page when we're reviewing over 45 templates). It's nearly impossible for clients to find their own tasks.