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!
