Alex,
thank you very much!! This is great news.
So the solution, presently, is to patch the
/opt/rt4/share/html/Articles/Elements/MaybeNeedsSetup file by copying it
to the "local" tree, right?
Do I understand it correctly that this is a bug in RT that will be fixed
in future releases?
Cris
On 26/01/2015 17:31, Alex Vandiver wrote:
> On Mon, 26 Jan 2015 11:46:09 +0000 Guadagnino Cristiano
> <guadagnino.cristi...@creval.it> wrote:
>> I have found this code, that tests if the warning needs to be shown:
>>
>> my $Classes = RT::Classes->new( $session{'CurrentUser'} );
>> $Classes->LimitToEnabled();
>> $Classes->RowsPerPage(1);
>> return if $Classes->First;
>>
>> If I understand correctly, if there is at least one class for which
>> the CurrentUser is enabled, the warning is *not* shown. However, I
>> see the warning even though I am enabled to see two classes, and I
>> can correctly see/edit/create articles in those classes.
>>
>> I do not have this problem is my test environment, where I did do the
>> upgrade but I did NOT reconfigure groups and queues like I did in
>> production. So I beleieve the problem is related to some missing
>> permission, but I cannot find any.
> Ah -- I believe I know. While tickets do their ACL at the database
> level by default in 4.2, the same is not true of Articles and Classes.
> As such, your user likey does not have permission to see the _first_
> enabled class that is returned, which results in the warning message
> being shown.
>
> Pushing Class ACLs down into SQL would be one fix (though quite
> complex). The simpler fix is likely to remove the ->RowsPerPage, as
> doing a query for all enabled Classes is not, by any means, a large
> query for most instances.
> - Alex
