Incident Template issue in ServiceDesk 7.5
No matter whether or not I have the 'user only template' box checked, it seems like the template can only be viewed by the original creator. I don't believe this is expected behavior, so can anyone else confirm this?
Looking at the SD.Feeder.TechnicianIncidentForms project, templates are loaded by the 'Init Data (Non-Cached) and Declarations' embedded model. This grabs all templates and then runs a configurable sort on them to check to see if the template creator is either 'System' or the user accessing the form. This tells me that when the 'user only template' box is not checked, the system should save the template with a creator of 'System'. When I checked the IMIncidentTemplate table directly, this is not happening. The mapping definition seems to be hardcoded to the EnsembleSecurityToken.Email value, rather than a dynamic mapping based on the value UserOnlyTemplate.
I think I'm reading this right, I just want some confirmation of the bug before I change the single value mapping component.
Comments 2 Comments • Jump to latest comment
I'm just going to assume this is a bug and post my solution. Independant confirmation would still be nice, though, so please comment.
Also, this solution does bring up some interesting questions for me. First, does this mean that all users can delete or modify this template? The only permission I see that would relate to this is the control over the Submit Incident (Advanced) form (Service.Items.AdvancedIncident), so I guess as long as you trust someone to access that form you must also trust them to not mess up the templates. Second, assuming I'm right about the first, would the best solution be to add a column to the template table that determines whether or not a template is global while keeping the 'CreatedBy' column as a way to track who did create a template and possibly limit editing to the original creator?
If a post solves your issue, please mark it as a solution. It makes these forums better for everyone.
Michael,
This is a known issue that was addressed in KB #TECH200154.
Would you like to reply?
Login or Register to post your comment.