Toni,<br><br>My answers are inline:<br><br>
* I (think I) need custom permissions and custom roles. Eg. if an email<br>
comes in, I'd like to grant the requestor role based on the value of<br>
a custom field and the email, so one person out of a group can open<br>
a ticket, and anyone in the group can reply by email.<br>A: By granting the right "ModifyTicket" only to Owners <b><i>Globally,</i></b> 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.<br>
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.<br><br>* I would like to restrict access to individual fields of a ticket in a<br>
way that peole with certain roles can only see and/or set a subset of<br>
values. Eg. I'd like to grant "resolve" and "reject" to Requestor,<br>
but not "re-open" or similar. Or, with CustomFields, I'd like to be<br>
able to allow Requestor to set a custom field to one, or several,<br>
values out of a subset of possible values, but only once (eg. to<br>
mark a ticket as relevant for an SLA), while disallowing him/her to<br>
change their mind later.<br>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.<br>
<br>* I do not yet understand how to select widgets for fields in RT. Eg.<br>
for a custom field which can take one of several values, I'd like to<br>
be able to choose a drop-down selection widget, or a set of radio<br>
buttons. So far, I get a multi-selection field, which is dead ugly.<br>
It also looks like I have to dive into the templates to re-arrange<br>
the widgets. Plus, RT imho seems to be quite wasteful of screen<br>
real estate (book?).<br>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.<br>
<br>Hope this helps.<br><br>Kenn<br>LBNL<br><br><div class="gmail_quote">On Thu, Sep 30, 2010 at 3:19 AM, Toni Mueller <span dir="ltr"><<a href="mailto:support@oeko.net">support@oeko.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Hi,<br>
<div class="im"><br>
On Thu, 30.09.2010 at 07:56:27 +0200, Emmanuel Lacour <<a href="mailto:elacour@easter-eggs.com">elacour@easter-eggs.com</a>> wrote:<br>
> to let the requestor see the tickets they created, just set ShowTicket<br>
> right to role group "Requestor" in global or per queue group rights.<br>
<br>
</div>thank you, that worked.<br>
<div class="im"><br>
> to revoke this right when ticket is taken ... that needs code changes.<br>
<br>
</div>I have encountered some questions which are hopefully answered in the<br>
book, although I don't have it yet. I'd like to share the questions<br>
nonetheless, though, and would eg. much appreciate if someone could<br>
tick them off as "read the book", or "maybe in 4.0/5.0", or eg. "wrong<br>
tree".<br>
<br>
So far, we were/are working with roundup, and thus my idea about how a<br>
TTS should work, or my habits using one, might be skewed... Likely I've<br>
just not yet taken in the way RT works.<br>
<br>
<br>
Anyway, off the top of my head and in no particular order:<br>
<br>
* I (think I) need custom permissions and custom roles. Eg. if an email<br>
comes in, I'd like to grant the requestor role based on the value of<br>
a custom field and the email, so one person out of a group can open<br>
a ticket, and anyone in the group can reply by email.<br>
<br>
* I would like to restrict access to individual fields of a ticket in a<br>
way that peole with certain roles can only see and/or set a subset of<br>
values. Eg. I'd like to grant "resolve" and "reject" to Requestor,<br>
but not "re-open" or similar. Or, with CustomFields, I'd like to be<br>
able to allow Requestor to set a custom field to one, or several,<br>
values out of a subset of possible values, but only once (eg. to<br>
mark a ticket as relevant for an SLA), while disallowing him/her to<br>
change their mind later.<br>
<br>
I'd like to have a track record of all such activity.<br>
<br>
I thought this could be modelled with a certain permission, like eg.<br>
"SelectAttributeOutOfSubsetOnce", and grant this to someone having a<br>
role of eg. "ForeignUser", which is calculated across their user's<br>
attributes (like eg. email + some custom fields). Using groups<br>
instead of roles could quickly become unwieldy, but would probably<br>
require less customization, and is less flexible (of course).<br>
<br>
* I would like to grant some people to add more users of their<br>
organisation (company), but they should be limited to have eg. their<br>
association set in a custom field, not changable by that user, and<br>
he should also not be able to grant more rights to them, but less<br>
(eg., prevent them from removing (their own) user(s)). IOW, I'd like<br>
to have hierarchical user management.<br>
<br>
* I do not yet understand how to select widgets for fields in RT. Eg.<br>
for a custom field which can take one of several values, I'd like to<br>
be able to choose a drop-down selection widget, or a set of radio<br>
buttons. So far, I get a multi-selection field, which is dead ugly.<br>
It also looks like I have to dive into the templates to re-arrange<br>
the widgets. Plus, RT imho seems to be quite wasteful of screen<br>
real estate (book?).<br>
<br>
* I'd like to attach logic to certain fields, like applying pre-set<br>
expiry/escalation strategies and so on, depending on the field's<br>
value, or on the combination of values for a set of fields (book?).<br>
<br>
<br>
Last but not least, my RT is not really operational right now. So far,<br>
it's a semi-working toy installation. Is it advisable to take the<br>
plunge and upgrade to 3.9.x now, or will it be safer to get it working<br>
first and upgrade later? For 4.0 some massive changes were announced,<br>
but I can't yet understand the full impact. I also expect less<br>
documentation and more bugs, and a cleaner architecture. Would you run<br>
your production tracker(s) on 3.9?<br>
<br>
<br>
TIA!<br>
<br>
<br>
<br>
Kind regards,<br>
<font color="#888888">--Toni++<br>
</font><div><div></div><div class="h5"><br>
<br>
RT Training in Washington DC, USA on Oct 25 & 26 2010<br>
Last one this year -- Learn how to get the most out of RT!<br>
</div></div></blockquote></div><br>