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 <falc...@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] > falc...@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] > falc...@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] > r...@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.lesin...@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] > r...@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.lesin...@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] > t...@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:falc...@bestpractical.com > > 2. mailto:falc...@bestpractical.com > > 3. > https://github.com/bestpractical/rt/compare/stable...4.0%2Fcontext-on-custom-fields > > 4. mailto:r...@bestpractical.com > > 5. mailto:jim.lesin...@gmail.com > > 6. mailto:r...@bestpractical.com > > 7. mailto:jim.lesin...@gmail.com > > 8. http://groups.pm/ > > 9. mailto:t...@bestpractical.com > > 10. http://issues.bestpractical.com/Ticket/Display.html?id=16946 >