Let's solve a long-standing bug?

I’ve taken this as far as I can. I’m challenging someone
with more RT development experience to find the bug :slight_smile:

I’ve been told “That’s the way it’s always been” and that
a patch was welcome.


When modifying ‘Basics’ (or even specifically ‘Custom Fields’)
in the web UI, one is presented with a form rightfully only
showing the fields one has perms to modify.

When one submits that form with changes, the resulting
page shows all fields, editable, regardless of the user’s
permission to modify.


In Ticket/Elements/EditCustomFields, if you change:

% while ( my $CustomField = $CustomFields->Next ) {
% next unless $CustomField->CurrentUserHasRight(‘ModifyCustomField’);

to this:

% while ( my $CF = $CustomFields->Next ) {
% if (! $CF->CurrentUserHasRight(‘ModifyCustomField’)) {
% $RT::Logger->error($session{‘CurrentUser’}->Name . " NO Modify
rights for " . $CF->Name);
% next;
% } else {
% $RT::Logger->error($session{‘CurrentUser’}->Name . " YES Modify
rights for " . $CF->Name);
% }

a) The appropriate debug lines are logged when one is viewing
an “initial” Modify.html. There is, in my case, the appro-
priate single custom field noted as modifiable.

b) As a ‘result’ page, debug lines are logged indicating EVERY
field is modifiable

c) All debug lines in a + b indicate the correct current user> On Mon 29.Mar’10 at 20:14:17 -0400, Jeff Blaine wrote:

Although… I just noticed something kooky when playing with
this. I don’t know if the list accepts images, so I’ll send
to you this once.

rt-prob1.jpg shows me editing a ticket as a user who has
no privs to modify AffectedEmployeeDetails (which does not
even show up, as expected).

Cool. That’s perfect.

However, if I add new info to AffectedEmployeeNumbers, which
I do have modify privs for, the resulting screen (rt-prob2.jpg)
gives me a seemingly-writeable text entry box for
AffectedEmployeeDetails instead of hiding it from me as above.

Sure, trying to change AffectedEmployeeDetails gives me a
permission denied when I try to save, but… why hide it once
and not always?

On 3/29/2010 7:56 PM, Jesse Vincent wrote:

Sadly, I knew about that, and had tested it to work just hours
before posting this. In those few hours I ended up in
share/html/Tickets/Elements/EditCustomFields to add the
display of $CustomField->Description information for the
viewer. I got sidetracked in that file and implemented
something I had already found a solution to.

More sadly, I posted it publicly :slight_smile:

laugh It happens to the best of us.