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 <[email protected]> wrote: > > Hi, > > On Thu, 30.09.2010 at 07:56:27 +0200, Emmanuel Lacour < > [email protected]> 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! >
RT Training in Washington DC, USA on Oct 25 & 26 2010 Last one this year -- Learn how to get the most out of RT!
