[rt-users] user's rights on tickets
Kenneth Crocker
kfcrocker at lbl.gov
Thu Sep 30 19:58:32 EDT 2010
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
LBNL
On Thu, Sep 30, 2010 at 3:19 AM, Toni Mueller <support at oeko.net> wrote:
>
> Hi,
>
> On Thu, 30.09.2010 at 07:56:27 +0200, Emmanuel Lacour <
> elacour at 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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20100930/029ad6de/attachment.htm>
More information about the rt-users
mailing list