[rt-users] rt 4.0.5 - Autocomplete field type for external custom field does not work for non root user

Jim Lesinski jim.lesinski at gmail.com
Tue Mar 13 11:33:38 EDT 2012


Absolutely no problem. Do you want me to do anything with the original
ticket?  [rt3 #19056]

It seems that these two issues I am experiencing are related to the same
underlying issue. I can open a separate ticket for this or update that
ticket if you feel it is appropriate.


On Tue, Mar 13, 2012 at 11:28 AM, Kevin Falcone
<falcone at bestpractical.com>wrote:

> On Mon, Mar 12, 2012 at 10:47:10PM -0400, Jim Lesinski wrote:
> >    Yep. In fact I was just looking at this issue and I traced the error
> out to line 311 in
> >    Principals.pm, which is the section of code below. If I just stick a
> "return 1;" above that
> >    section of code everything works. Coincidentally, I believe that this
> will also fix another
> >    bug I submitted [rt3 #19056] regarding permissions and the
> autocomplete custom field when not
> >    using a custom data source.
> >    Anyway, it has something to do with this bit of code about caching
> but my perl is to newb for
> >    a proper fix :)
> >    Hope that is helpful.
>
> Do you mind turning your replication recipe into a real bug report at
> rt-bugs @ bestpractical.com ?  Mention that you tested the branch and
> it didn't help, it sounds like we need some extensions to that branch.
>
> Thanks for finding some interesting corner cases
>
> -kevin
>
> >
> >  # Construct a hashkeys to cache decisions:
> >
> >
> >  # 1) full_hashkey - key for any result and for full combination of uid,
> right and objects
> >
> >
> >  # 2) short_hashkey - one key for each object to store positive results
> only, it applies
> >
> >
> >  # only to direct group rights and partly to role rights
> >
> >
> >  ****my $full_hashkey = join (";:;", $self->id, $args{'Right'});
> >
> >
> >  ****foreach ( @{ $args{'EquivObjects'} } ) {
> >
> >
> >  ********my $ref_id = $self->_ReferenceId($_);
> >
> >
> >  ********$full_hashkey .= ";:;".$ref_id;
> >
> >
> >
> >  ********my $short_hashkey = join(";:;", $self->id, $args{'Right'},
> $ref_id);
> >
> >
> >  ********my $cached_answer = $_ACL_CACHE->fetch($short_hashkey);
> >
> >
> >  ********return $cached_answer > 0 if defined $cached_answer;
> >
> >
> >  ****}
> >
> >
> >
> >  ****{
> >
> >
> >  ********my $cached_answer = $_ACL_CACHE->fetch($full_hashkey);
> >
> >
> >  ********return $cached_answer > 0 if defined $cached_answer;
> >
> >
> >  ****}
> >
> >
> >
> >  ****my ( $hitcount, $via_obj ) = $self->_HasRight(%args);
> >
> >
> >
> >  ****$_ACL_CACHE->set( $full_hashkey => $hitcount ? 1 : -1 );
> >
> >
> >  ****$_ACL_CACHE->set( join(';:;',  $self->id, $args{'Right'},$via_obj)
> => 1 )
> >
> >
> >  ********if $via_obj && $hitcount;
> >
> >
> >
> >  ****return ($hitcount);
> >
> >
> >    On Mon, Mar 12, 2012 at 10:22 PM, Kevin Falcone <[1]
> falcone at bestpractical.com> wrote:
> >
> >      On Mon, Mar 12, 2012 at 06:52:00PM -0400, Jim Lesinski wrote:
> >      > get the branch name to work because it included a forward slash
> so I used the commit id...
> >      > Maybe someone can chime in?
> >      > This didn't work: git format-patch
> rt-4.0.5..4.0/context-on-custom-fields --stdout >
> >      > fields.patch
> >      > git format-patch
> >      >
> 94acf9055ccb6a7368d539dcc8f1d2684016e8ef..2b3265a91a4e5e8cdf724ea218ea30fa501f73b2
> >      --stdout >
> >      > fields.patch
> >
> >      It's not the forward slash, those are absolutely legal, the problem
> is
> >      that you had no local copy of the branch.
> >
> >      git checkout 4.0/context-on-custom-fields
> >      git format-patch 4.0-trunk or git format-patch rt-4.0.5
> >      will get you the 4 patches (your --stdout > file.patch would work
> >      too). Although your incant *should* have created the correct set of
> >      files.
> >
> >      After applying the patches, clearing your mason cache and restarting
> >      apache, are you still seeing a warning in the debug logs?
> >
> >      -kevin
> >      > 5. Change to the RequestTracker install directory
> >      > cd /opt/rt4
> >      > 6. This shows what changes are in the patch:
> >      > git apply --stat /tmp/patch/stable/fields.patch
> >      > 7. This allows you to try out the patch:
> >      > git apply --check /tmp/patch/stable/fields.patch
> >      > 8. And Finally this applies the patch:
> >      > git apply -v /tmp/patch/stable/fields.patch
> >      > On Mon, Mar 5, 2012 at 12:11 PM, Kevin Falcone <[2][2]
> falcone at bestpractical.com> wrote:
> >      >
> >      > On Mon, Mar 05, 2012 at 08:58:40AM -0500, Jim Lesinski wrote:
> >      > > I copied over the changed files from the branch you suggested
> into
> >      > > /local/lib/RT/CustomField.pm
> >      > > /local/lib/RT/Interface/Web.pm
> >      > > /local/lib/RT/Transaction.pm
> >      > > Then I cleared the mason cache and restarted apache. I ended up
> with this error.
> >      >
> >      > Unfortunately, 4.0/context-on-custom-fields predates some work we
> did
> >      > in 4.0.5, so copying the files will take out code we added later.
> >      > You really want to apply patches (or do a local merge of that
> branch)
> >      > rather than trying to pull full files out of it.
> >      >
> >      > Github will show you what changes you'd need to apply here, but
> I'm
> >      > not sure how to get it to give you a patch file.
> >      >
> >      > [3][3]
> https://github.com/bestpractical/rt/compare/stable...4.0%2Fcontext-on-custom-fields
> >      >
> >      > -kevin
> >      > > error: Undefined subroutine
> &HTML::Mason::Commands::MaybeRedirectToApproval called at
> >      > > /opt/rt4/share/html/Ticket/autohandler line 14.
> >      > > context: ...
> >      > > 10: |(?<!\.html))
> >      > > 11: $
> >      > > 12: }ix;
> >      > > 13:
> >      > > 14: MaybeRedirectToApproval(
> >      > > 15: Whitelist => $whitelist,
> >      > > 16: ARGSRef => \%ARGS,
> >      > > 17: );
> >      > > 18:
> >      > > ...
> >      > > code stack: /opt/rt4/share/html/Ticket/autohandler:14
> >      > > /opt/rt4/sbin/../local/lib/RT/Interface/Web.pm:538
> >      > > /opt/rt4/sbin/../local/lib/RT/Interface/Web.pm:285
> >      > > /opt/rt4/share/html/autohandler:53
> >      > >
> >      > > Have I done something wrong? Must I overwrite these files
> instead of adding to the local
> >      > > directory? I did move the files manually into my local copy of
> 4.0.5 but I thought that
> >      > would
> >      > > work.
> >      > > Thanks for the help. I am thinking a work around would be to
> just assign permissions to
> >      > the
> >      > > field. Maybe I should just wait for 4.0.6.
> >      > > Jim
> >      > > On Wed, Feb 29, 2012 at 6:29 AM, Ruslan Zakirov <[1][4][4]
> ruz at bestpractical.com> wrote:
> >      > >
> >      > > Hi,
> >      > >
> >      > > You need fixes from 4.0/context-on-custom-fields branch.
> >      > > On Tue, Feb 28, 2012 at 20:32, Jim Lesinski <[2][5][5]
> jim.lesinski at gmail.com> wrote:
> >      > > > I turned on debug (*new to me) and it looks like this is the
> relevant error
> >      > > > in the logs:
> >      > > >
> >      > > > Feb 28 11:22:11 buf-rtdev RT: Permission denied. User #63 has
> no
> >      > > > SeeCustomField right on CF #13
> >      > > >
> >      > > > If I assign SeeCustomField directly to the custom field (#13)
> for RTUser,
> >      > > > then the autocomplete value works.
> >      > > >
> >      > > > Maybe I am missing something here with permissions... Should
> I be assigning
> >      > > > group or specific user permissions on a field by field basis?
> Up until now I
> >      > > > had only put users in groups and assigned group permissions
> to queues. I do
> >      > > > have a couple nested groups as well, but no permissions
> explicitly defined
> >      > > > on a per field basis. It seems like it should be working
> though since it
> >      > > > does work for other field types, just not autocomplete.
> >      > > >
> >      > > >
> >      > > >
> >      > > >
> >      > > >
> >      > > > On Tue, Feb 28, 2012 at 10:46 AM, Ruslan Zakirov <[3][6][6]
> ruz at bestpractical.com>
> >      > > > wrote:
> >      > > >>
> >      > > >> Hi,
> >      > > >>
> >      > > >> Anything in debug logs when this doesn't work?
> >      > > >>
> >      > > >>
> >      > > >> On Tue, Feb 28, 2012 at 19:38, Jim Lesinski <[4][7][7]
> jim.lesinski at gmail.com>
> >      > > >> wrote:
> >      > > >> > The user (RTuser) is Privileged.
> >      > > >> >
> >      > > >> > Here is an outline of the permissions assigned to RTUser:
> >      > > >> >
> >      > > >> > RTUser is a member of a GroupA that has OwnTicket,
> StealTicket and
> >      > > >> > TakeTicket rights on the queue1.
> >      > > >> >
> >      > > >> > GroupA is a member of GroupB, which has CommentOnTicket,
> CreateTicket,
> >      > > >> > ReplyToTicket, Watch, SeeCustomField, SeeQueue, and
> ShowTicket
> >      > > >> > permissions
> >      > > >> > on queue1.
> >      > > >> >
> >      > > >> > To test permissions, I just now assigned every single
> permission to
> >      > > >> > RTUser
> >      > > >> > on the General Rights, Rights for Staff, and Rights for
> Administrators
> >      > > >> > tabs
> >      > > >> > to RTUser for queue1 and still the autocomplete values do
> not populate.
> >      > > >> >
> >      > > >> > If I go to Tools - Configuration - Global - User Rights
> and add RTUser
> >      > > >> > and
> >      > > >> > then check in "Do anything and everything", the
> autocomplete values work
> >      > > >> > for
> >      > > >> > [5][8][8]groups.pm.
> >      > > >> >
> >      > > >> >
> >      > > >> >
> >      > > >> > On Tue, Feb 28, 2012 at 10:03 AM, Thomas Sibley <[6][9][9]
> trs at bestpractical.com>
> >      > > >> > wrote:
> >      > > >> >>
> >      > > >> >> On 02/28/2012 09:17 AM, Ruslan Zakirov wrote:
> >      > > >> >> >> I have set up a custom data source for a custom field
> as outlined
> >      > > >> >> >> in external_custom_fields.pod. It seems that
> everything works fine
> >      > > >> >> >> and
> >      > > >> >> >> I get
> >      > > >> >> >> pick list data populated into the custom field for all
> field types
> >      > > >> >> >> when
> >      > > >> >> >> logged in as an account with root privileges. However,
> if I switch
> >      > > >> >> >> to
> >      > > >> >> >> an
> >      > > >> >> >> account that has non-root privileges, all the fields
> types work as
> >      > > >> >> >> expected
> >      > > >> >> >> other than the autocomplete field type. For some
> reason this field
> >      > > >> >> >> type
> >      > > >> >> >> returns no data when I am logged in as a non-root user
> account.
> >      > > >> >> [snip]
> >      > > >> >> >> Has anyone else run into this? Can someone else verify
> this in their
> >      > > >> >> >> environment?
> >      > > >> >> >>
> >      > > >> >> >
> >      > > >> >> > [7][10][10]
> http://issues.bestpractical.com/Ticket/Display.html?id=16946
> >      > > >> >>
> >      > > >> >> To clarify, that bug applies to Self Service
> (unprivileged) users only.
> >      > > >> >> It's not clear if your non-root user accounts that you
> tested with are
> >      > > >> >> privileged or unprivileged. If they are privileged,
> autocomplete CFs
> >      > > >> >> should work just fine.
> >
> > References
> >
> >    Visible links
> >    1. mailto:falcone at bestpractical.com
> >    2. mailto:falcone at bestpractical.com
> >    3.
> https://github.com/bestpractical/rt/compare/stable...4.0%2Fcontext-on-custom-fields
> >    4. mailto:ruz at bestpractical.com
> >    5. mailto:jim.lesinski at gmail.com
> >    6. mailto:ruz at bestpractical.com
> >    7. mailto:jim.lesinski at gmail.com
> >    8. http://groups.pm/
> >    9. mailto:trs at bestpractical.com
> >   10. http://issues.bestpractical.com/Ticket/Display.html?id=16946
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20120313/70629fac/attachment.html>


More information about the rt-users mailing list