Hello Hassan,
Did Francisco's advice help?
Looking at this from a different angle, I am wondering why you are issuing your Employees access to "Issues" (detail_iss.htmpl) rather than Incidents (detail_in.htmpl) - or even Call Requests (detail_cr.htmpl).
As end users, you typically would not be expecting them to be using Issues, which is more typically used by a higher support tier, or done away with altogether.
See here for an accessible description of the difference between Issues and Incidents: Issues vs. Incidents
Your Analysts would then take an Incident/Call Request and raise an Issue, Change Order or Problem as required.
If you do use Incidents or Call Requests (See Options Manager variable employee_intf_incident_support to enable), then you could perhaps use Web Screen Painter to directly remove the Priority field from the form, rather than going via Source Code. Using Design rather than Source would keep your customisation under CA Support guidelines. I haven't tested this, but it may be worth trying on a test system.
Or alternatively, you could leave the field on the screen, but use Data Partitions so that Employees could not change the value and they get a Default value instead.
Finally, you could again leave the field on the screen, but only give Employees restricted access to some of the values. So for example they could choose only Priority 4, or only Priority 3 or 4. Again, that would leave you with a supported environment, rather than going via the Source code, which should be avoided where possible.
See this document for the procedure: How to mask out Priority values in Service Desk.
Just some different approaches to think about which may give better results in the long term.
Thanks, Kyle_R.