Communication going to issues vs. projects

[Stryker]

Hi -- We have a common problem where requestors will go to their issue/request and add comments or documents after that request has been converted to a project.  We have added training and communication to our users about this -- but people still make this mistake.  Is there a way to lock the issue once we convert it to a project so users will then be forced to only communicate or add to documents folder in the project? 

[PeggyGr]

This is something we have struggled with also. I have created a requestor dashboard to try to work around this but they still tend to go to the request rather than the project. It would be great if the request was locked once it was converted to a project. 

[imgrund]

Hi - there are a few things that come to mind for me...

1. Create a custom dashboard for the requester, top part is requests that haven't been converted, and the bottom part is requests that have. BUT... instead of including the original request name, just use Resolve Project Name. Then there isn't a hyperlink to take them back to the original request.
2. After the request is converted to a project, go back to the request and change the sharing so that they can't see it at all, or to View and in Advanced Setting uncheck add documents. (If you have Fusion or another way to API calls, maybe this can be automated). 
3. I've used a Journal Entry report on my main dashboard to see who has been loading documents to requests already converted or adding status updates. It is way more of a passive thing than proactive, but you can also use that for reporting to tell a manager "Look, love Billy Bob, but this is the 12th time this month he has added documentation to the request after it has been converted, which is clearing against our process and policy"

Hope at least one of these helps... or inspires you to an even better solution. 

[Rafal_Bain]

My recommendation would be inline with previous ones:

1. build custom dashboard for raising and managing requests

2. embedded request forms work nicely

3. have dedicated reports with filtered content so that users always land on the required page task/issue/project