Hi.
Updating joblist.php you changed
$where = getAccesRestrictionClause('JoblistDefinition', false);
$where .= "and nameChecklistable = 'Activity' ";
$where .= "and idType = " . $lstActivity[0]->idActivityType;
in
//$where = getAccesRestrictionClause('JoblistDefinition', false);
$where .= "nameChecklistable = 'Activity' ";
//$where .= "and idType = " . $lstActivity[0]->idActivityType;
I presume you wished to remove the dot to avoid to keep previous value in $where
Best regards
Hi,
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.
Hi antonio, you can find documentation of this report here: https://www.projeqtor.org/fr/forum-fr/3-propose-evolutions/7848-new-features-to-projeqtor?limitstart=0#16156
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.
I think I fixed all issues here:
https://github.com/papjul/projeqtor/commit/fdad937f32c7cfdeae158e81d4b2ac657261630e
and here https://github.com/papjul/projeqtor/commit/f0d1e1557552e45b1fd3a90932392af8c567bed6
In the future, if you need help in modifying this report, feel free to ask, we use this report a lot here.
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.
Hi,
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.
I understood the need, I'm talking about the specifications, and not how it will be done neither, but what functional cases will be allowed exactly to the users. What kind of report do we want to show to users? Is this something that is useful? (I mean, not just make a generic report, for the purpose of being generic if this becomes too complex with non-used cases) What filters (report parameters) can they use? etc
I think that existing is not far from target :
Selection :
Propose to select a project (required) and an activity of the project (optional)
Report :
If only project is selected :
list all activities of the project, and sub-projects (recursively) of this project
if activity is selected
list all activities which have selected activity as parent activity, and also their sub-activities (recursively)
for all activities :
if a joslist is defined for the activity (joblist definition exists), list je joblistdefinition
for all listed joblistdefinitions
Edit a table for the joblist definition listing all activities concernend by this joblistdefintion, showing job status (like existing) of the joblist
Edit summary for all activities at the end of the table of each joblist definition table
Hope this is clear 😉