Lock requests once converted to a project

[#1]

Description - Once a request is converted to a project and assigned, it would be helpful if there was an option to "lock" the original request. 

Why is this feature important to you - Often, those who request projects add updates or documents to the original request versus the project and forget to @ whoever they are trying to communicate with, and those comments or documents are missed. 

How would you like the feature to work - Once converted, the request is locked (automatically would be preferred) but could also include an option for System Admins or Project Managers to unlock or make a change if necessary. 

Current Behaviour - I have found a workaround for this within the dashboard (removing the link to the request) but it is much too easy for requesters to click on "Requests" and then click the original request, which then leads to the original issue. 

[#2]

Hi,

It works quite good in present scenario. In addition, once we convert to a project and the possibility (to choose, link / not link) to lock request. Plus, it is locked, then request must shows the planned completion date of project as planned completion date of request created. This should be changed to automatically or we can make it as option to choose.

Best regards,

Kundan

[#3]

Yes! This has always been a pain point.  We like to keep the original request (issue) to monitor how long it takes for people to fill out the proper forms to even become a project so we like to have that history, but once it becomes a project it would be amazing to have an option to lock it after conversion because people find it and put stuff in there and no one sees it.  

[#4]

I generally like this idea but would absolutely need the ability for Sys Admin or PM to be able to unlock the issue to make changes. We do run into instances, more often than you would think, where we want to update both the resolving project and the issue.

I'd even be fine with Sys Admin ability to unlock, then anyone to make changes, and Sys Admin to re-lock.

[#5]

Yes! I put this Idea in the old Workfront One in 2020 so would love to get movement on this again.

[#6]

Out of curiosity...When you lock a request, what would you want to happen with any updates to the original request (regardless whether the update is made by email or integration or on the object directly)?  

[#7]

@ewanh 

This is the main problem for us when users comment on the original request vs the converted project. Any comment or document that has been added does not show up in the converted project and often gets missed. 

My thought here is that when they request comes in, any documents or comments that have originally been added convert, but once converted, a locked request would no longer allow a document or comment to be added.

With the option for a system admin to unlock if necessary, this would allow any changes to this form to be requested through the system admin, but would provide that safety net that nothing gets missed once converted. 

[#8]

@MegSault Thank you...

So the problem as you describe is likely felt by a lot of Workfront users (myself included). 

I also think more options for granular controls by System or Group Admins is desired as Heather mentioned and you noted as well is always desirable.

I'm curious if there is agreement on what the desired action to documents or comments on the "converted from" now locked object would be as I could see a handful of different possible directions there. For my work, as we convert requests to projects regularly,  I would want comments and documents to be added to the "converted to" object.  Curious what @ElenaDooley @Heather_Kulbacki @LB103 and @Kundanism think.  

[#9]

@ewanh  I think if the converted issue is locked to prevent comments or documents from being added, it would be great when someone clicked in the Update box (or on the Add New doc button or dragged a doc to the issue) a message would pop up letting them know: this issue has been converted to a project, the project team will not see anything added here, and providing a link to the project.

I suspect you will have Admins who want control over that message because I've talked to some who do not give the requestor access to the converted project - so that message would cause confusion and a bad experience for their users.

[#10]

Or if anything in the Updates on a Request are transferred to the projects update stream and at-tagged to the project owner automatically.

And yeah, we decided to let the Requests stay live, but we basically do everything we can to hide link to the project becuse they don't have access. So if a warning message was to come-up, customizing it would be ideal rather than the equivalent of "Access Denied" or getting the pointless access requests.

[#11]

Thank you @Heather_Kulbacki and @CalvinFold for those great insights.  If anyone can capture more likes on this from their friends/colleagues it will help the possibility for consideration and a response from our product teams.