Greater control over request settings: lock issues, prevent conversion to tasks/projects

[#1]

Prevent issues/requests from being converted into tasks/projects:

I would love for a setting that completely prevents users from converting certain request types (ones I select as an admin, not all requests) into projects? Despite our attempts to educate users on specific work processes, some users convert requests into projects, even though they are to be managed only as requests.

Add option to lock issues from editing after they are converted to task/project:

Our users have a habit that's hard to break in which they will continue to update an Issue that's been converted to a Project, rather than update the Project. They just don't realize the difference between the two objects, and I realize part of it is ongoing training even though this has been communicated over and over. I know that in Project Preferences > Tasks & Issues there is an option to delete an issue once it's been converted to a project but we do not want to have the original issue deleted. Could we add an option so that issues can be 'locked' from editing after conversion?

[#2]

I would love to be able to lock an issue that's been converted to a project.

[#3]

We're in a similar conundrum:

We don't want to delete the original request/issue, but we also don't want them editing it after it's converted to a project or task.

[#4]

Agreed on not allowing edits / collaboration on a request once it's converted to a project/task. It would be magical if any links to the request became jump links to the resolving object, so users couldn't open the request.

[#5]

Great idea! I would also like to restrict editing of ALL requests, (converted or not) by limiting permissions to read only so that even updates cannot be posted. View permission still allows for commenting, unfortunately. And it seems that the Requester access cannot read the requests at all.

[#6]

Has there been any more discussion on this? Requestors are constantly adding updates or additional requests to requests that have already been converted to a project. This is extremely confusing to the designers and creates issues when the requestors don't tag the appropriate users especially given they are commenting on a request vs. a converted project.

[#7]

Hi Megan - I've not seen any formal updates per se, and I have the exact issue you do. However, I have found a bit of a workaround in addition to training the requestors. Once you have your request in and are confident it no longer should have updates (the updates can be made into the project), you can click the three horizontal dots next to the title and go to sharing, and change the contribute setting to View Only. This essentially locks the requestor from adding updates to the request. Then when you convert to a project, just make sure the requestor has whatever appropriate permissions.

[#8]

Hi Megan - I've not seen any formal updates per se, and I have the exact issue you do. However, I have found a bit of a workaround in addition to training the requestors. Once you have your request in and are confident it no longer should have updates (the updates can be made into the project), you can click the three horizontal dots next to the title and go to sharing, and change the contribute setting to View Only. This essentially locks the requestor from adding updates to the request. Then when you convert to a project, just make sure the requestor has whatever appropriate permissions.