Possibly...
I don"t concider this report as reliable.
It's been designed by contributor in very specific way (considering all activities listed have same type).
It has to be generalized and fiabilized.
babynus, I just updated from 6.0.8 to 6.2.4 and found this report to be broken, noticeably CSV export line breaks issues, or all jobs (I have about 100 jobs in my database!) are shown despite not being part of joblists related to the activities shown.
There is something that bothers me with this report.
You designed it in a very specific way, that fits your need but is much too specific to integrate community version.
It tried to extend it to set it more generic, but sure changes may not be accurate.
My main concerns about design of the report are:
- report shows joblists for activities being sub-activities of one parent activity : this is very restrictive and involves a 2 level structure, wich is not always the case
- when selecting a project, it only shows activites of the project, but generic design is to also include activities of subprojects of select project
- all activities are considered of the same activity type corresponding to single joblistdefinition : this is much too restrictive (but maybe the way I extended it is not the good one, maybe we should split report for each type, or for each joblistdefinition).
- desciption is displayed in UPPERCASE : maybe you need this, but this is often considered as very agressive and may set long descriptions as unreadable
I understand, maybe you should make a specification of what you're expecting exactly from this report and how? Maybe we can find a common field. Because currently, it is broken and unuseful for everyone.
As for description field, I didn't remember I did this on the report as we already uppercase all descriptions as they are typed in activities directly, so I didn't put it back in the commits showed in my previous post. Edit: You're right, I put back the mb_strtoupper() function, my mistake, I just wanted to fix the linebreaks issue in CSV.
The need is just to have it work the way you did it, but without the restrictions that are valid only on your way to build projects :
- show joblists summary even for activities that do not have parent activity
- take into account that displayed activities may be of several types, and so linked to several joblistdefinitions.
That is almost all...
The first item is easy : remove constraint "idActivity in not null"
Second item may be more difficult to do.
Possibly, the best may should be to draw one table per joblistdefiniton (regroup selected activities per joblistdefinition) so that each table concerns only one joblistdefinition.
En poursuivant votre navigation, vous acceptez le dépôt de cookies tiers destinés au bon fonctionnement et à la sécurisation du site (gestion de session, reCaptcha) et à une analyse statistique anonymisée des accès sur notre site (Google Analytics). Si vous vous inscrivez, les informations que vous fournirez ne seront jamais divulguées à un tiers sous quelque forme que ce soit. En savoir plus
Cookies settings
×
Functional Cookies
Ce site utilise des cookies pour assurer son bon fonctionnement et ne peuvent pas être désactivés de nos systèmes. Nous ne les utilisons pas à des fins publicitaires. Si ces cookies sont bloqués, certaines parties du site ne pourront pas fonctionner.
Session
Please login to see yours activities!
Other cookies
Ce site web utilise un certain nombre de cookies pour gérer, par exemple, les sessions utilisateurs.
Support us on Capterra
