to let the requestor see the tickets they created, just set ShowTicket
right to role group “Requestor” in global or per queue group rights.
thank you, that worked.
to revoke this right when ticket is taken … that needs code changes.
I have encountered some questions which are hopefully answered in the
book, although I don’t have it yet. I’d like to share the questions
nonetheless, though, and would eg. much appreciate if someone could
tick them off as “read the book”, or “maybe in 4.0/5.0”, or eg. “wrong
So far, we were/are working with roundup, and thus my idea about how a
TTS should work, or my habits using one, might be skewed… Likely I’ve
just not yet taken in the way RT works.
Anyway, off the top of my head and in no particular order:
I (think I) need custom permissions and custom roles. Eg. if an email
comes in, I’d like to grant the requestor role based on the value of
a custom field and the email, so one person out of a group can open
a ticket, and anyone in the group can reply by email.
I would like to restrict access to individual fields of a ticket in a
way that peole with certain roles can only see and/or set a subset of
values. Eg. I’d like to grant “resolve” and “reject” to Requestor,
but not “re-open” or similar. Or, with CustomFields, I’d like to be
able to allow Requestor to set a custom field to one, or several,
values out of a subset of possible values, but only once (eg. to
mark a ticket as relevant for an SLA), while disallowing him/her to
change their mind later.
I’d like to have a track record of all such activity.
I thought this could be modelled with a certain permission, like eg.
“SelectAttributeOutOfSubsetOnce”, and grant this to someone having a
role of eg. “ForeignUser”, which is calculated across their user’s
attributes (like eg. email + some custom fields). Using groups
instead of roles could quickly become unwieldy, but would probably
require less customization, and is less flexible (of course).
I would like to grant some people to add more users of their
organisation (company), but they should be limited to have eg. their
association set in a custom field, not changable by that user, and
he should also not be able to grant more rights to them, but less
(eg., prevent them from removing (their own) user(s)). IOW, I’d like
to have hierarchical user management.
I do not yet understand how to select widgets for fields in RT. Eg.
for a custom field which can take one of several values, I’d like to
be able to choose a drop-down selection widget, or a set of radio
buttons. So far, I get a multi-selection field, which is dead ugly.
It also looks like I have to dive into the templates to re-arrange
the widgets. Plus, RT imho seems to be quite wasteful of screen
real estate (book?).
I’d like to attach logic to certain fields, like applying pre-set
expiry/escalation strategies and so on, depending on the field’s
value, or on the combination of values for a set of fields (book?).
Last but not least, my RT is not really operational right now. So far,
it’s a semi-working toy installation. Is it advisable to take the
plunge and upgrade to 3.9.x now, or will it be safer to get it working
first and upgrade later? For 4.0 some massive changes were announced,
but I can’t yet understand the full impact. I also expect less
documentation and more bugs, and a cleaner architecture. Would you run
your production tracker(s) on 3.9?