Hello,
In RT 3.6.5, /Admin/Queues/Modify.html, there are still references to
the session cache of queues with key “create_in_queues”. This is a
legacy of the older (i.e. 3.4) , simpler, single queue cache from
/Elements/SelectNewTicketQueue. This cache scheme has been expanded
in 3.6 to cover multiple queue caches with cache keys that look like:
“SelectQueue—” . $session{‘CurrentUser’}->Id .
"—$CheckQueueRight—$ShowAllQueues"
Anyway, the code in Admin/Queues/Modify.html is still trying to
delete the older-style cache and has no effect. This can be verified
by creating a new queue and checking the “create” queue drop-downs on
the home page - the new queue does not appear.
I haven’t supplied a patch because I wanted to suggest alternative
solutions. When a queue is created or modified you could
a) Look through all session keys and delete the ones that match the
new queue-cache format ( starts with “SelectQueue—” ). The problem
with this is a performance hit while the cache is then reconstructed
- a lot of queues means a delay. The deletion & recreation of the
caches seems to be a brute-force way of getting the queue listing
right. Another way (we use this at MIT) is:
b) Instead of deleting the queue caches & forcing the slow reload,
just modify them:
- New queue: add the new queue to the appropriate caches
- Disabled queue: remove the queue from the caches
- Enabled queue: add the new queue to the appropriate caches
If someone lets me know a preferred way, I’ll be happy to send a patch.
Thanks,
Steve
Hello,
In RT 3.6.5, /Admin/Queues/Modify.html, there are still references to
the session cache of queues with key “create_in_queues”. This is a
legacy of the older (i.e. 3.4) , simpler, single queue cache from
/Elements/SelectNewTicketQueue. This cache scheme has been expanded
in 3.6 to cover multiple queue caches with cache keys that look like:
“SelectQueue—” . $session{‘CurrentUser’}->Id .
“—$CheckQueueRight—$ShowAllQueues”
Anyway, the code in Admin/Queues/Modify.html is still trying to
delete the older-style cache and has no effect. This can be verified
by creating a new queue and checking the “create” queue drop-downs on
the home page - the new queue does not appear.
I haven’t supplied a patch because I wanted to suggest alternative
solutions. When a queue is created or modified you could
a) Look through all session keys and delete the ones that match the
new queue-cache format ( starts with “SelectQueue—” ). The problem
with this is a performance hit while the cache is then reconstructed
- a lot of queues means a delay. The deletion & recreation of the
caches seems to be a brute-force way of getting the queue listing
right. Another way (we use this at MIT) is:
b) Instead of deleting the queue caches & forcing the slow reload,
just modify them:
- New queue: add the new queue to the appropriate caches
- Disabled queue: remove the queue from the caches
- Enabled queue: add the new queue to the appropriate caches
If someone lets me know a preferred way, I’ll be happy to send a patch.
b) sounds the most sane. I’d lvoe a patch.
a) Look through all session keys and delete the ones that match the
new queue-cache format ( starts with “SelectQueue—” ). The problem
with this is a performance hit while the cache is then reconstructed
- a lot of queues means a delay. The deletion & recreation of the
caches seems to be a brute-force way of getting the queue listing
right. Another way (we use this at MIT) is:
b) Instead of deleting the queue caches & forcing the slow reload,
just modify them:
- New queue: add the new queue to the appropriate caches
- Disabled queue: remove the queue from the caches
- Enabled queue: add the new queue to the appropriate caches
If someone lets me know a preferred way, I’ll be happy to send a patch.
b) sounds the most sane. I’d lvoe a patch.
Though hm. This will only fix it for the current session. I wonder if we
could just be clever and do a join on the ACL table these days. I think
we have a lot more of the infrastructure we’d need to do a sane query
than we sued to.