Problem: We use a support group in Remedy to store templates… this can cause a couple of problems:
- People can have tickets assigned to them via a template group instead of an actual support group
- When people who accidentally have a template group assigned as their default group, when they open a ticket, that template group will be the owner, and will show up in consoles for everyone else assigned to that template group
You can’t do a Modify All in the People form to edit support groups. There doesn’t seem to be another form made for this purpose.
Solution: The form “CTM:Support Group Association” allows you to edit assignment availability using Edit All, but when you enter data in the Company and Support Org fields, it doesn’t actually filter on those fields. Turns out that the Support Group ID field is the only one that gets filtered on. You have to look up the Support Group ID using the Support Group form, and filter based on that.
Next step… creating a macro to do this and creating a Windows scheduled task to run the macro daily.
Background: We control access to templates via special template support groups.
This is actually pretty simple and works for the most part. The only issue that really comes up is that sometimes users will assign a ticket to someone by way of a template group, instead of an actual support group. This causes the ticket to show up in the consoles of everyone else assigned to that template group.
Problem: The People form doesn’t allow you to modify anything to do with assigned support groups by a modify all.
- Using the Support Groups form, look up the Support Group ID (SGP###):
- Open the “CTM:Support Group Association” form
- Search using only the Support Group ID. (Using the Company/Organization/Group menus will not work!)
In Incident and Problem, you can create a custom filter to answer questions like “What tickets are assigned to me?” or “Which of my pending tickets haven’t been updated today?” quite easily using Build Search Qualification.
The actual field names behind those columns in Change are “ASCHG” and “Change Request Status”… who knew. Still not in the field dropdown, but they can be typed in manually at least.
Apparently BOXI 3.1 SP3 requires the 32 bit Oracle 10g client to be installed, though you wouldn’t know it from this error message:
"Failure to validate the database credential has a potential to crash the database at a later stage. Enter the correct information. (STU00104)"
Installing the Oracle 10g client on Red Hat 5.5 is a whole other story. At least it was for us.