Absolutely no problem. Do you want me to do anything with the original
ticket? [rt3 #19056]
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@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@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@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@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@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@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@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]
Login
> > >> >>
> > >> >> 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
- mailto:falcone@bestpractical.com
- mailto:falcone@bestpractical.com
-
https://github.com/bestpractical/rt/compare/stable...4.0%2Fcontext-on-custom-fields
- mailto:ruz@bestpractical.com
- mailto:jim.lesinski@gmail.com
- mailto:ruz@bestpractical.com
- mailto:jim.lesinski@gmail.com
- http://groups.pm/
- mailto:trs@bestpractical.com
- Login
