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.
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.
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.
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.
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:
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.
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:
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,
KaiOn 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.
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:
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(): someurl.com - Diese Website steht zum Verkauf! - Informationen zum Thema someurl.
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();
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:
This is correct, without a call to SetContextObject some rights cannot
be found.
This is why I was curious about how your coworker gets the
SeeCustomField right (is he an admincc, requestor, owner, etc)
since it changes the way the right is searched for.
Your fix looks mostly correct, except that the function you’re
modifying should live in ObjectCustomFieldValue_Overlay.pm, but that
isn’t your fault, it is code from 5+ years ago.