I add a new canned response. the canned respond saved well, but it not showing in the list

when i try to add again, it give me the following error

but it is in the list in the ticket response

I'm using v1.15.1

Please help us to help you by reading and following the posting guidelines located in this thread: Please read before requesting assistance. The more information you give us the better we will be able to assist you. Thank you.

Environment details? (if you can then see Admin panel -> Dashboard -> Information)

5 days later

I already post the information image. whaat else do you need?

Try uploading to current 1.15.2.

From what you are saying:

  • I made a canned response and saved it.
  • I cannot save the same canned response a second time.

Sounds to me like it is working like it should be. The system tells you that it already exists.
I' m not seeing a problem here.

canned respond "CH-Kepada Bpk CSM" not showing in the Knowledgebase - Canned Responses

Go to the database and delete the canned response and try again?

4 years later

Hello there,
I appreciate that this is quite an old thread, but I thought this may help someone.
Encountering the same issue, I noted the canned response department had an effect.
You will not be able to view the canned response at /scp/canned.php unless the agent you are logged in as has access to that department.
Check this in /scp/staff.php and click on the agent, then "access".
In my case the department had a parent and I just needed to add this sub department to my access and all was well. Incidentally, you can still access the canned response even without adding access if you know the canned response ID number which you can then add into the URL. It is simply "hidden" from the canned response list if you don't have access to the department.

    KevinTheJedi Hey there, I've gone ahead and reported that ID thing. It didn't bother me at all - I just came across it while trying to troubleshoot the above issue as to why my canned response wasn't showing in the list. But I can imagine scenarios where such accessibility would be unwanted!

    The department feature is something I do like for providing access to the helpdesk from third parties. Lets say I provide support to a client with 100+ locations and they want to log into our help desk to view their tickets only. The departments are a great way to do this.

    Few issues with it in that I can't seem to restrict them from the dashboard so I need to manually edit the core files to hide the dashboard. Same with the knowledgebase as we don't really want them seeing our internal knowledgebase full of stuff not relevant to them and potentially sensitive info.
    Lastly the queues - would be good to hide the queues from them too. Appreciate the content of the queues can be hidden from them using departments but if you have a number of queue and sub queue names on your helpdesk it might also give away sensitive info to a clients that you don't want them to see. Or it just looks cluttered with irrelevant data to an extent.

    On another positive note the departments seem to be a good way for contractors to access your helpdesk. Lets say you have outsourced the support of all printers to a particular company, and you want them to take ownership of issues through your helpdesk. Great. Although I've not set it up for this yet I do have a potential use case for it and it seems to be pretty similar to the above where a client is accessing their tickets.

        m-law

        Why are your clients agents? Why not keep them as users and utilize Organizations with ticket sharing enabled? Meaning everyone in the organization will be able to login and see the tickets in their org or that they own directly.

        Cheers.

            KevinTheJedi The issue with users is they can only see tickets within the organisation. For better or worse we have each of the client's sites listed as a separate organisation. This means we can allocate equipment to each site using custom lists.
            Sites tend to have several unique attributes or notes that render them more static than a user.

            I did however suggest to our admin person that we set this client up as a single organisation for the very reason you mention, and figure another way to document site equipment etc. But she seemed hell bent on doing it the other way and created all the organisations on the system of her own accord.

            Each site/organisation we deal with has a contact (user) as well, usually the shop manager. So am not sure if we'd want them logging in and seeing tickets for all the other sites. It might confuse them.

              Write a Reply...