Hi,
I’m trying to set up RT (latest) for us, but have a problem
understanding rights. We want to give users the ability to see their
tickets, and only their tickets, including tickets they submitted,
but which are not “taken”. Ideally, the user could be a group (eg. an
IT department) with several human members, who generally should have
the same rights. Likewise, if some person out of such a “user” group, a
confirmation should be sent to the group as a whole, not only to that
member of the group.
The only way I see how to do this, at this moment, is to create one
queue per user/group, and assign this user/group rights to only this
queue (use a special group if there is more than one person to deal
with).
I’d like to have the ability to (automatically) assign access rights on
a per-ticket basis instead, but don’t see how this could be done.
It would be nice if you could share some tips or pointers!
Kind regards,
–Toni++
Hi,
I’m trying to set up RT (latest) for us, but have a problem
understanding rights. We want to give users the ability to see their
tickets, and only their tickets, including tickets they submitted,
but which are not “taken”. Ideally, the user could be a group (eg. an
IT department) with several human members, who generally should have
the same rights. Likewise, if some person out of such a “user” group, a
confirmation should be sent to the group as a whole, not only to that
member of the group.
The only way I see how to do this, at this moment, is to create one
queue per user/group, and assign this user/group rights to only this
queue (use a special group if there is more than one person to deal
with).
I’d like to have the ability to (automatically) assign access rights on
a per-ticket basis instead, but don’t see how this could be done.
It would be nice if you could share some tips or pointers!
to let the requestor see the tickets they created, just set ShowTicket
right to role group “Requestor” in global or per queue group rights.
to revoke this right when ticket is taken … that needs code changes.
Hi,
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
tree”.
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?
TIA!
Kind regards,
–Toni++
Toni,
My answers are inline:
-
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.
A: By granting the right “ModifyTicket” only to Owners Globally, and not
to anyone else (except maybe the AdminCc of a Queue), you automatically
restrict who can change the status of a Ticket. Further, if you write a scip
that has a condition based on the “From” or some Custom Field, you can
automatically set the owner to whomever should get that ticket for each
particular Queue.
We do this. We have a large Support Group and each member get assigned
ownership of all tickets that have a Custom Field Value for a particular CFO
Organization Code.
-
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.
A: You can do the same type of thing with Ticket Status. Create a Custom
Field that only certain groups can See/Modify and a scrip that based on a
value change to that Custom Field, changes the Ticket Status. We also do
this. Works great.
-
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?).
A: There is code available to override how a Custom Field is presented. We
use it to present “Select One Value” Custom Fields as a “Drop-Down” list
(see only one value but scan by pressing down arrow). This code should be in
the wiki, but if not, I can pass it along to you.
Hope this helps.
Kenn
LBNLOn Thu, Sep 30, 2010 at 3:19 AM, Toni Mueller support@oeko.net wrote:
Hi,
On Thu, 30.09.2010 at 07:56:27 +0200, Emmanuel Lacour < elacour@easter-eggs.com> wrote:
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
tree”.
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?
TIA!
Kind regards,
–Toni++
RT Training in Washington DC, USA on Oct 25 & 26 2010
Last one this year – Learn how to get the most out of RT!