[rt-users] ExecuteCode by Queue AdminCc groups on RT::System
Hello,
My production system contains a few ACL's that do not dump correctly
using rt-dump-metadata. They end up multiple times in our dump as:
{
Right : ExecuteCode,
GroupDomain : RT::System-Role,
GroupType : AdminCc
},
(In JSON for readability)
These are in reality applied to the AdminCC group principal of queues.
What is the bug here?
Is it that I should be able to see such a right in the Global rights
page, or should the right not have been granted since the upgrade step
(3.9.1 iirc)?
(It is a bit of a weird delegation of rights, but a few of our AdminCc
groups have indeed the right to edit templates).
Thanks,
Kai
signature.asc
Description: OpenPGP digital signature
Re: [rt-users] CustomField Transactions Options?
Hi mloughran,
On 6/24/13 5:58 PM, Emmanuel Lacour wrote:
On Mon, Jun 24, 2013 at 08:26:53AM -0700, namespace wrote:
I have a custom field entry that when selected, I want to automatically add a
watcher to the ticket in question. As it stands, this CustomField called
*'Service Type'* has an entry for PO's that when selected should add
'purchas...@fibermedia.net' as a watcher without having the operator
manually add the entry. I don't see anywhere in the customfield options to
add a watcher, only to notify existing individuals associated with the
ticket. Anyone got any input on this?
I ran into a quite similar case just a few months ago.
You have to do this with a scrip.
Our Custom Condition Code checks if the customfield 'Severity' is changed:
return 0 unless $self-TransactionObj-Type eq 'CustomField';
my $cf = RT::CustomField-new( $self-CurrentUser );
$cf-SetContextObject( $self-TransactionObj );
$cf-Load( $self-TransactionObj-Field );
return 1 if $cf-Name() eq 'Severity';
return 0;
And for our custom action prepare (or cleanup, I never know which to pick):
for ($self-TransactionObj-NewValue) {
if (m/^Major$/) {
$self-TicketObj-AddWatcher(Type = 'Requestor', Email =
'major-incident@name.local');
}
elsif (m/^Critical$/) {
$self-TicketObj-AddWatcher(Type = 'Requestor', Email =
'critical-incident@name.local');
}
}
for ($self-TransactionObj-OldValue) {
if ( m/^Critical$/ ) {
$self-TicketObj-DeleteWatcher(Type = 'Requestor', Email =
'critical-incident@name.local');
}
elsif ( m/^Major$/ ) {
$self-TicketObj-DeleteWatcher(Type = 'Requestor', Email =
'major-incident@name.local');
}
}
return 1;
The added (or removed) watcher addresses expand to SMS in this case.
Regards,
Kai
signature.asc
Description: OpenPGP digital signature
Re: [rt-users] Notify owners of new ticket not working totally
On 2013-06-19 15:49, Cena, Stephen (ext. 300) wrote: I'm using the NotifyOwner plug in for extra notifications: http://search.cpan.org/dist/RT-Extension-NotifyOwners/lib/RT/Extension/NotifyOwners.pm [1] The Scrip is working, however its also sending out an email even if the ticket gets an owner. It should only fire when the ticket is created and the owner is Nobody In Particular. Here is my Scrip: Desc: On Create Unowned Ticket Condition: On Create Action: Notify Potential Owners Template: Global Template: Potential owners notification Stage: TransactionCreate Custom Condition: return 1 if $self-OwnerObj-Id == $RT::Nobody-Id; return 0; = Is my custom condition wrong? Hi Stephen, You should select Userdefined from the Condition pulldown menu, or it will not run your custom condition code block. Regards, Kai -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] make upgrade-database error
Hi Kevin, Thanks for coming back on this. I only saw today that you responded. For the search archive I'm including the DBD::Pg error again: DBD::Pg::st execute failed: ERROR: more than one row returned by a subquery used as an expression On 5/28/13 9:44 PM, Kevin Falcone wrote: On Fri, May 03, 2013 at 02:47:24PM +0200, Kai Storbeck wrote: I dug this thread up from the archives, as I ran into the same error while doing a test upgrade. IIUC, every CustomFieldValue needs to be updated to contain a category field from the old attributes table. Since this doesn't break on a 'clean' RT 3.8 with categories, I - like ruz - suspect some bad data in your tables. I'd like to see what he requested. Understandable. SELECT ObjectId, Content FROM Attributes WHERE Name = 'Category' AND ObjectType = 'RT::CustomFieldValue'; Or potentially a slightly modified form: SELECT Content, CustomFieldValues.id, CustomFieldValues.Name FROM Attributes, CustomFieldValues WHERE Attributes.Name = 'Category' AND ObjectType = 'RT::CustomFieldValue' AND CustomFieldValues.id = Attributes.ObjectId; I've sent you the file off-list. There's a few fields that I'd prefer not being archived. Tweak that to find the places with multiple values. I'm not amazed by the output, did we insert disturbing data? Regards, Kai signature.asc Description: OpenPGP digital signature -- RT Training in Seattle, June 19-20: http://bestpractical.com/training
Re: [rt-users] CustomField with Link values to doesn't link correctly
Hi Kevin,
Thanks for your initial answer in October. Other issues took my attention for a
while, but I found interest again after someone contacted me describing exactly
the same problem.
After a small learning curve with the perl debugger, I came to the conclusion
that the 2 customfields aren't initialized the same way, so I dug around a
little more, and found that most CustomFields get a call to SetContextObject()
after initialize. In Ticket-CustomFields this happens, but called from the
ObjectCustomFieldValue not:
# diff -ruN ~/rt-3.8.7/lib/RT/ObjectCustomFieldValue.pm
/opt/rt3/lib/RT/ObjectCustomFieldValue.pm
--- /usr/home/kai/rt-3.8.7/lib/RT/ObjectCustomFieldValue.pm 2009-12-11
18:27:20.0 +0100
+++ /opt/rt3/lib/RT/ObjectCustomFieldValue.pm 2010-01-05 20:49:32.0
+0100
@@ -173,6 +173,7 @@
sub CustomFieldObj {
my $self = shift;
my $CustomField = RT::CustomField-new($self-CurrentUser);
+ $CustomField-SetContextObject( $self-Object );
$CustomField-Load($self-__Value('CustomField'));
return($CustomField);
}
This patch seems to work around _my_ problem, but... since you guys are the
experts: Is this the correct way of resolving this issue? Are there large
performance penalties or other side effects?
Regards,
Kai
On Oct 1, 2009, at 5:28 PM, Kevin Falcone wrote:
On Thu, Oct 01, 2009 at 11:36:57AM +0200, Kai wrote:
Hi,
I'm using RT 3.8.4, patched to 3.8.5 to see if that fixed it (since
that was CF related) on a debian system.
One of my coworkers wasn't able to click on a customfield that had a
Link values to setting, while I am. The main difference: He has
the right to SeeCustomField, and I have the SuperUser right.
He gets an empty
a href= target=_new512178/a
Me:
a href=https://someurl/fubar?id=512178;
target=_new512178/a
Attached is a perlscript that immitate
html/Elements/ShowCustomFields. You need a ticket with a customfield
containing 1 value with a Link value To-setting, and a user thats
permitted the necessary rights (SeeQueue, ShowTicket,
SeeCustomField).
Somewhere after the calls from a $customfield's value back to its
CustomFieldObj() it loses its permission for the 'SeeCustomField'
right. I'm stupified after looking at this code too long; I can't
see where or why it fails for this user.
How is the marcelv user getting the SeeCustomField right?
Is it from being in a group, direct user assignment, being a Requestor
or AdminCc of the ticket?
Just making a test user in a copy of 3.8.5 that has SeeQueue,
ShowTicket and SeeCustomField granted to privileged users lets a test
user see the link as expected and runs your test script with:
Found ticket: 1
customfield-LinkValueTo():
http://foo.com/id=__id__value=__CustomField__
value-LinkValueTo(): http://foo.com/id=1value=asdf
value-Content(): asdf
value-CustomFieldObj-CurrentUserHasRight(SeeCustomField): 1
value-CustomFieldObj-id(): 1
CustomField-CurrentUserHasRight(SeeCustomField): 1
CustomField-id(): 1
If you have local lib mods, I suggest checking to make sure that
they're up-to-date with 3.8.5, there are a lot of new calls to
ContextObject and SetContextObject that could break CF permissions if
they're lost.
-kevin
Could someone assist me in solving this? I sincerely doubt it is a
missing right?
This user has: SeeQueue, SeeCustomField, ModifyCustomField,
AssignCustomField, ShowTicket, ShowTicketComments, CreateTicket,
ReplyToTicket, CommentOnTicket, OwnTicket, ModifyTicket,
DeleteTicket, TakeTicket, StealTicket.
My output:
Found ticket: 2047497
customfield-LinkValueTo(): http://someurl.com/search?id=__CustomField__
value-LinkValueTo():
value-Content(): 512178
value-CustomFieldObj-CurrentUserHasRight(SeeCustomField):
value-CustomFieldObj-id(): 40
CustomField-CurrentUserHasRight(SeeCustomField): 1
CustomField-id(): 40
#!/usr/bin/perl -w
use strict;
# debian locations:
use lib '/usr/share/request-tracker3.8/lib';
use lib '/etc/request-tracker3.8';
use RT;
use RT::User;
RT::LoadConfig();
RT::Init;
$| = 1;
my $username = shift || 'marcelv';
my $ticketno = shift || 2047497;
my $canonicalright = 'SeeCustomField';
my $user = RT::User-new($RT::SystemUser);
$user-Load($username);
my $ticket = RT::Ticket-new($user);
$ticket-Load($ticketno);
print Found ticket: . $ticket-Id . \n;
my $allcustomfields = $ticket-CustomFields;
# These snippets are taken from html/Elements/ShowCustomFields
while (my $cf = $allcustomfields-Next ) {
my $values = $ticket-CustomFieldValues( $cf-Id );
# I'm assuming a single value customfield, with a template.
my $linked = $cf-LinkValueTo;
my $v = $values-First();
if ( $linked ) {
print customfield-LinkValueTo(): $linked\n;
print value-LinkValueTo(): , $v-LinkValueTo , \n;
print value-Content(): , $v-Content , \n;
print value-CustomFieldObj-CurrentUserHasRight($canonicalright): ,
