Re: [rt-users] creating tickets with CF values without ModifyCustomField right
Thanks, Chris! I appreciate the detailed response and suggestions I suspect you are quite right and for at least some of the custom fields, your way would be a much better/easier solution! To be honest, I don't think I had considered (or even knew about?) being able to control custom field permissions on BOTH the custom field level AND queue level. The one thing that might cause me problems is that at least one of the fields should not be viewable by the requestors once it is in the new queue. It's sort of a priority field, and we don't want them to know if their priority gets downgraded. Since it seems that it's an all-or-nothing to see custom fields on the queue level, then I don't have the option to hide some fields but allow them to see others. In any case, I'm definitely going to test your idea for at least some of the fields we have here! Thanks, Brent -Original Message- From: Christian Loos [mailto:cl...@netcologne.de] Sent: Tuesday, June 03, 2014 6:18 AM To: rt-users@lists.bestpractical.com Cc: Parish, Brent; elac...@easter-eggs.com Subject: Re: creating tickets with CF values without ModifyCustomField right Am 02.06.2014 22:46, schrieb Parish, Brent: > We have this same problem here. > If you don't want to wait for the feature request to be implemented, here is > one way around it: > > I ended up creating a second set (copy) of the custom fields. > I named them the same thing, but with an underscore character appended. > (e.g. If the custom field is called "Application" the second/copy > custom field would be called "Application_") > > Then I gave 'everyone' the right to edit "Application_" but not "Application". > I created a scrip that fires on Ticket Create that looks for all custom > fields with the underscore appended and copies them to the custom field of > the same name (but without the underscore). The same scrip also moves the > ticket to the appropriate queue. > > In this way, the users can now create new tickets and set the initial values > of the custom fields. But once the ticket has been created (thanks to the > scrip), it is moved into the proper queue and the users do not have rights to > change the custom field values there. > > Since this 'general' queue needs to have both sets of custom fields applied > to it (so the scrip can copy values from one set to the next), I also had to > customize the Self Service screen to hide the custom fields that did not have > the underscore appended (otherwise the user get confused seeing two copies of > [almost] the exact same field name). > > Just an option that seems to work well for us. =) > > - Brent I think for you situation there is a much simpler solution without duplicate custom fields: Grant Everyone SeeCustomField on the custom field level and ModifyCustomField on the queue level only for the queue where the ticket is created. If the user create the ticket they have the ModifyCustomField from the queue level. If you then move the ticket to the right queue they have only SeeCustomField from the custom field level. I will think about if the "ticket create in one queue and then move to another queue" will fit in my needs. As we actually use a custom form within RT to create the ticket there is a much simpler solution to allow users with SeeCustomField to set custom field values on ticket create. Attached a patch. This patch isn't enough if you use the built-in ticket create form, as Elements/EditCustomFields limit the custom fields to which the user has ModifyCustomField right. To fix this you have to inspect in Elements/EditCustomFields the request path and if it's '/Ticket/Create.html' then limit the custom fields by SeeCustomField right otherwiese limit by ModifyCustomField right. May one of the RT developers can have a look on this suggestions if this would fit for inclusion in RT 4.4. Also it should be discussed if SeeCustomField is sufficient to create tickets with custom field values or if a new right SetCustomFieldValuesOnCreate should be introduced. Chris -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] creating tickets with CF values without ModifyCustomField right
Am 02.06.2014 22:46, schrieb Parish, Brent: > We have this same problem here. > If you don't want to wait for the feature request to be implemented, here is > one way around it: > > I ended up creating a second set (copy) of the custom fields. > I named them the same thing, but with an underscore character appended. > (e.g. If the custom field is called "Application" the second/copy custom > field would be called "Application_") > > Then I gave 'everyone' the right to edit "Application_" but not "Application". > I created a scrip that fires on Ticket Create that looks for all custom > fields with the underscore appended and copies them to the custom field of > the same name (but without the underscore). The same scrip also moves the > ticket to the appropriate queue. > > In this way, the users can now create new tickets and set the initial values > of the custom fields. But once the ticket has been created (thanks to the > scrip), it is moved into the proper queue and the users do not have rights to > change the custom field values there. > > Since this 'general' queue needs to have both sets of custom fields applied > to it (so the scrip can copy values from one set to the next), I also had to > customize the Self Service screen to hide the custom fields that did not have > the underscore appended (otherwise the user get confused seeing two copies of > [almost] the exact same field name). > > Just an option that seems to work well for us. =) > > - Brent I think for you situation there is a much simpler solution without duplicate custom fields: Grant Everyone SeeCustomField on the custom field level and ModifyCustomField on the queue level only for the queue where the ticket is created. If the user create the ticket they have the ModifyCustomField from the queue level. If you then move the ticket to the right queue they have only SeeCustomField from the custom field level. I will think about if the "ticket create in one queue and then move to another queue" will fit in my needs. As we actually use a custom form within RT to create the ticket there is a much simpler solution to allow users with SeeCustomField to set custom field values on ticket create. Attached a patch. This patch isn't enough if you use the built-in ticket create form, as Elements/EditCustomFields limit the custom fields to which the user has ModifyCustomField right. To fix this you have to inspect in Elements/EditCustomFields the request path and if it's '/Ticket/Create.html' then limit the custom fields by SeeCustomField right otherwiese limit by ModifyCustomField right. May one of the RT developers can have a look on this suggestions if this would fit for inclusion in RT 4.4. Also it should be discussed if SeeCustomField is sufficient to create tickets with custom field values or if a new right SetCustomFieldValuesOnCreate should be introduced. Chris --- /opt/rt4/lib/RT/CustomField.pm 2014-04-30 11:06:36.521983426 +0200 +++ /opt/rt4/local/lib/RT/CustomField.pm 2014-06-03 11:00:20.903356879 +0200 @@ -1527,7 +1527,11 @@ ); my $obj = $args{'Object'} or return ( 0, $self->loc('Invalid object') ); -unless ( $self->CurrentUserHasRight('ModifyCustomField') ) { +my $right = ( ref $obj eq 'RT::Ticket' and $self->ValuesForObject($obj)->Count == 0 ) +? 'SeeCustomField' +: 'ModifyCustomField'; + +unless ( $self->CurrentUserHasRight($right) ) { return ( 0, $self->loc('Permission Denied') ); } -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] creating tickets with CF values without ModifyCustomField right
We have this same problem here. If you don't want to wait for the feature request to be implemented, here is one way around it: I ended up creating a second set (copy) of the custom fields. I named them the same thing, but with an underscore character appended. (e.g. If the custom field is called "Application" the second/copy custom field would be called "Application_") Then I gave 'everyone' the right to edit "Application_" but not "Application". I created a scrip that fires on Ticket Create that looks for all custom fields with the underscore appended and copies them to the custom field of the same name (but without the underscore). The same scrip also moves the ticket to the appropriate queue. In this way, the users can now create new tickets and set the initial values of the custom fields. But once the ticket has been created (thanks to the scrip), it is moved into the proper queue and the users do not have rights to change the custom field values there. Since this 'general' queue needs to have both sets of custom fields applied to it (so the scrip can copy values from one set to the next), I also had to customize the Self Service screen to hide the custom fields that did not have the underscore appended (otherwise the user get confused seeing two copies of [almost] the exact same field name). Just an option that seems to work well for us. =) - Brent -Original Message- From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Emmanuel Lacour Sent: Monday, June 02, 2014 9:21 AM To: rt-users@lists.bestpractical.com Subject: Re: [rt-users] creating tickets with CF values without ModifyCustomField right On Mon, Jun 02, 2014 at 02:44:14PM +0200, Christian Loos wrote: > Hi, > > is it possible to create tickets with CF values for users that don't > have the ModifyCustomField right? > Currently if fails with "Permission Denied" in > RT::CustomField->AddValueForObject(). > > We have some users that use the RT WebUI to create tickets and must > enter on ticket create some CF values. > The same users also have ShowTicket (and ShowQueue) right to get later > some informations about the ticket history. > This users are don't allowed to change CF values later on the tickets, > so I can't give them the ModifyCustomField right. > > It is also not obvious that you have to grant users the > ModifyCustomField right to be able to create tickets with CF values, > as they want to *Create* values and not *Modify* values. > As there isn't an CreateCustomField(Values) right I think at least for > ticket create it would be better if SeeCustomField would be sufficient > to create tickets with CF values. > Indeed there is only See/Modify customfield rights (not "set"). That's a known feature request: http://issues.bestpractical.com/Ticket/Display.html?id=14974 that is still unimplemented ... a patch may help this feature to be present in a 4.4 release i suppose ;) -- Easter-eggs Spécialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 43 35 00 76 mailto:elac...@easter-eggs.com - http://www.easter-eggs.com -- RT Training - Boston, September 9-10 http://bestpractical.com/training -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] creating tickets with CF values without ModifyCustomField right
On Mon, Jun 02, 2014 at 02:44:14PM +0200, Christian Loos wrote: > Hi, > > is it possible to create tickets with CF values for users that don't > have the ModifyCustomField right? > Currently if fails with "Permission Denied" in > RT::CustomField->AddValueForObject(). > > We have some users that use the RT WebUI to create tickets and must > enter on ticket create some CF values. > The same users also have ShowTicket (and ShowQueue) right to get later > some informations about the ticket history. > This users are don't allowed to change CF values later on the tickets, > so I can't give them the ModifyCustomField right. > > It is also not obvious that you have to grant users the > ModifyCustomField right to be able to create tickets with CF values, as > they want to *Create* values and not *Modify* values. > As there isn't an CreateCustomField(Values) right I think at least for > ticket create it would be better if SeeCustomField would be sufficient > to create tickets with CF values. > Indeed there is only See/Modify customfield rights (not "set"). That's a known feature request: http://issues.bestpractical.com/Ticket/Display.html?id=14974 that is still unimplemented ... a patch may help this feature to be present in a 4.4 release i suppose ;) -- Easter-eggs Spécialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 43 35 00 76 mailto:elac...@easter-eggs.com - http://www.easter-eggs.com -- RT Training - Boston, September 9-10 http://bestpractical.com/training
[rt-users] creating tickets with CF values without ModifyCustomField right
Hi, is it possible to create tickets with CF values for users that don't have the ModifyCustomField right? Currently if fails with "Permission Denied" in RT::CustomField->AddValueForObject(). We have some users that use the RT WebUI to create tickets and must enter on ticket create some CF values. The same users also have ShowTicket (and ShowQueue) right to get later some informations about the ticket history. This users are don't allowed to change CF values later on the tickets, so I can't give them the ModifyCustomField right. It is also not obvious that you have to grant users the ModifyCustomField right to be able to create tickets with CF values, as they want to *Create* values and not *Modify* values. As there isn't an CreateCustomField(Values) right I think at least for ticket create it would be better if SeeCustomField would be sufficient to create tickets with CF values. Chris -- RT Training - Boston, September 9-10 http://bestpractical.com/training