Re: [rt-users] Ticket replies not going to another queue
Kevin Falcone ha scritto: On Fri, May 30, 2014 at 03:07:05PM +, Guadagnino Cristiano wrote: While we understand this use case (and in fact have developed code for users who needed to be able to email other RT queues from inside RT): Is this something you have developed under a paid contract or is it part of the standard RT? If so, I may have missed something. It is something we have delivered to customers and has not seen a public release. Before public release, it would require refactorings to make supporting it in future releases easier and there has not been sufficient clamor nor support for it. -kevin Oh, ok thank you. Please add my +1 to this. Bye Cris -- 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
[rt-users] NotifyActor doesn't work anymore
hello all, my problem is that my notifyactor doesn't work anymore. the first time i used it, it worked and everytime there was a change or a new ticket we would get an email. but now it does't do anything. this is the way i configured it in RT_SiteConfig.pm *#notifyactor Set($NotifyActor, 1); * the strange thing was that when it stopped working it changed to *Set($NotifyActor, 0);* i changed it to 1 but now it doesn't do anything. does anybody know what to do here... i've tried almost everything. kind regards, martiniano -- View this message in context: http://requesttracker.8502.n7.nabble.com/NotifyActor-doesn-t-work-anymore-tp57579.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training - Boston, September 9-10 http://bestpractical.com/training
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
[rt-users] Mass email creating Tickets
Hi Guys I am fairly new to this RT stuff but a question I have is about scrips. I need a way to stop a ticket from being created when the email address provided is on a mass email. I have an email address which is used for users to send in a ticket, but the email is also on a countrywide distribution list which HR, Health and safety, etc use, everytime they send a mass email to everyone it creates a ticket in my RT. In my scrips I am able to change statuses depending on queues etc but when writing a scrip to sort this out I am stuck. I figure if I am able to say Email was sent to more than one person therefore update status to deleted. However, I am unsure on how to do such a thing. Any ideas? Thanks -- View this message in context: http://requesttracker.8502.n7.nabble.com/Mass-email-creating-Tickets-tp57582.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Mass email creating Tickets
Would it not be easier to remove your queue email from the distribution list; or am missing something? Jon Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: AdamThomas [adam.tho...@sgs.com] Received: Tuesday, 03 Jun 2014, 20:52 To: rt-users@lists.bestpractical.com [rt-users@lists.bestpractical.com] Subject: [rt-users] Mass email creating Tickets Hi Guys I am fairly new to this RT stuff but a question I have is about scrips. I need a way to stop a ticket from being created when the email address provided is on a mass email. I have an email address which is used for users to send in a ticket, but the email is also on a countrywide distribution list which HR, Health and safety, etc use, everytime they send a mass email to everyone it creates a ticket in my RT. In my scrips I am able to change statuses depending on queues etc but when writing a scrip to sort this out I am stuck. I figure if I am able to say Email was sent to more than one person therefore update status to deleted. However, I am unsure on how to do such a thing. Any ideas? Thanks -- View this message in context: http://requesttracker.8502.n7.nabble.com/Mass-email-creating-Tickets-tp57582.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training - Boston, September 9-10 http://bestpractical.com/training This email has been processed by Smoothwall Anti-Spam - www.smoothwall.net -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] Mass email creating Tickets
I have already tried that but the administrator is giving a hard time about it :/ Sent from Samsung Mobile Original message From: Jon Witts jwi...@queenmargarets.com Date: 06-03-2014 4:49 PM (GMT-05:00) To: rt-users@lists.bestpractical.com,Thomas, Adam (Lakefield) adam.tho...@sgs.com Subject: RE: [rt-users] Mass email creating Tickets Would it not be easier to remove your queue email from the distribution list; or am missing something? Jon Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: AdamThomas [adam.tho...@sgs.com] Received: Tuesday, 03 Jun 2014, 20:52 To: rt-users@lists.bestpractical.com [rt-users@lists.bestpractical.com] Subject: [rt-users] Mass email creating Tickets Hi Guys I am fairly new to this RT stuff but a question I have is about scrips. I need a way to stop a ticket from being created when the email address provided is on a mass email. I have an email address which is used for users to send in a ticket, but the email is also on a countrywide distribution list which HR, Health and safety, etc use, everytime they send a mass email to everyone it creates a ticket in my RT. In my scrips I am able to change statuses depending on queues etc but when writing a scrip to sort this out I am stuck. I figure if I am able to say Email was sent to more than one person therefore update status to deleted. However, I am unsure on how to do such a thing. Any ideas? Thanks -- View this message in context: http://requesttracker.8502.n7.nabble.com/Mass-email-creating-Tickets-tp57582.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training - Boston, September 9-10 http://bestpractical.com/training This email has been processed by Smoothwall Anti-Spam - www.smoothwall.nethttp://www.smoothwall.net/ Information in this email and any attachments is confidential and intended solely for the use of the individual(s) to whom it is addressed or otherwise directed. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Company. Finally, the recipient should check this email and any attachments for the presence of viruses. The Company accepts no liability for any damage caused by any virus transmitted by this email. All SGS services are rendered in accordance with the applicable SGS conditions of service available on request and accessible at http://www.sgs.com/en/Terms-and-Conditions.aspx -- RT Training - Boston, September 9-10 http://bestpractical.com/training
Re: [rt-users] remote sql server w/ ssl RT make upgrade-database problem
I had the same problem. As I find out the update-database task was trying to connect to the DB using root user, which I don't have access to instead of my RT database user. The upgrade-database was asking for password, but it did not asked for a user which should be used. So made a change in /sbin/rt-setup-database: my $dba_user = my_rt_database_user_name. -- View this message in context: http://requesttracker.8502.n7.nabble.com/remote-sql-server-w-ssl-RT-make-upgrade-database-problem-tp57521p57585.html Sent from the Request Tracker - User mailing list archive at Nabble.com. -- RT Training - Boston, September 9-10 http://bestpractical.com/training
