Warning in the articles overview page

RT Users
1

After upgrading to 4.2.9 and a subsequent deep reconfiguration of our groups, queues and group rights, we have this warning whenever we access the article overview page:

Setup needed

Before Articles can be used, your RT administrator must create Classeshttp://rtbkd.prod.bkd/Admin/Articles/, apply Article custom fields to them, and grant users rights on the classes and CFs.

An introduction to getting started with articleshttp://bestpractical.com/rt/docs/4.2/customizing/articles_introduction.html is available from Best Practical’s online documentationhttp://bestpractical.com/rt/docs/4.2/.

I have lost days looking for the problem in our configuration, without finding anyhting wrong. Actually, I can see and edit articles without problems.

What exactly is that triggers this warning?

Thank you in advance
Cris

2

Cris,

Which version did you upgrade from?

Have you created classes? It sounds like that might be the underlying problem.

Classes are similar to queues for Tickets to organize the articles – Customizing/Articles introduction - RT 4.2.17 Documentation - Best Practical

Aaron

3

Hi Aaron.
I upgraded (IIRC) from 4.2.3. And yes, I have a few classes and topics too. We are not new to articles in RT.

CrisOn 23/01/2015 21:06, Aaron McCormack wrote:
Cris,

Which version did you upgrade from?

Have you created classes? It sounds like that might be the underlying problem.

Classes are similar to queues for Tickets to organize the articles – Customizing/Articles introduction - RT 4.2.17 Documentation - Best Practical

Aaron

4

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.

Any help?

T.I.A.
CrisOn 26/01/2015 08:42, Guadagnino Cristiano wrote:
Hi Aaron.
I upgraded (IIRC) from 4.2.3. And yes, I have a few classes and topics too. We are not new to articles in RT.

Cris

Cristiano Guadagnino

Servizio Sistemi Dipartimentali, Periferici e DB
Bankadati Servizi Informatici Soc.Cons.P.A.
Gruppo bancario Credito Valtellinese
VIA TRENTO, 22 - 23100 SONDRIO
tel +39 0342522172 - fax +39 0342522997
guadagnino.cristiano@creval.it
www.creval.ithttp://www.creval.it

Il presente messaggio non è di natura personale ma inviato per esigenze lavorative; l’eventuale messaggio di risposta potrà essere conosciuto anche da altri soggetti diversi dall’originatore di questo messaggio per dette esigenze o per controllo aziendale. Questo messaggio, corredato dei relativi allegati, contiene informazioni da considerarsi strettamente riservate, ed è destinato esclusivamente al destinatario sopra indicato, il quale è l’unico autorizzato ad usarlo, copiarlo e, sotto la propria responsabilità, diffonderlo. Chiunque ricevesse questo messaggio per errore o comunque lo leggesse senza esserne legittimato è avvertito che trattenerlo, copiarlo, divulgarlo, distribuirlo a persone diverse dal destinatario è severamente proibito, ed è pregato di rinviarlo immediatamente al mittente distruggendone l’originale.

On 23/01/2015 21:06, Aaron McCormack wrote:
Cris,

Which version did you upgrade from?

Have you created classes? It sounds like that might be the underlying problem.

Classes are similar to queues for Tickets to organize the articles – Customizing/Articles introduction - RT 4.2.17 Documentation - Best Practical

Aaron

5

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
6

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?

CrisOn 26/01/2015 17:31, Alex Vandiver wrote:

On Mon, 26 Jan 2015 11:46:09 +0000 Guadagnino Cristiano guadagnino.cristiano@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