[rt-users] Let's solve a long-standing bug?

[Jeff Blaine]

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

I've been told "That's the way it's always been" and that
a patch was welcome.

PROBLEM:

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.

DEBUGGING:

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 :)
>>>
>>> *laugh* It happens to the best of us.
>
>
>
>