Thanks for the patch.

The idea to calculate organizatrion data only when on the corresponding screen may be a workaround for performance issue, but not definitive solution. Reports and other use of this data should not depend on way user worked (if he never goes to Organization screen but only looks at reports....)

Hello,

Here some details for calculations of work, etc on organizations :
Of course, 'non-calculation' is only effective if the 'useOrganizationBudgetElement' parameter is set to NO.
In this case, calculations are made on the fly on non-stored attributes specific to the instantiated Organization (useful only if one is on the detail screen of an organization). It is therefore totally useless to calculate them in another screen, since they will not be displayed.

On the other hand, there was an implementation error on the OrganizationMain construct which, if the 'useOrganizationBudgetElement' parameter is set to NO, systematically calculate and set hierarchic string. So I added a parameter avoiding this calculation and setting hierarchic string in the constructor ($organizationScreen).
In the previous patch, this parameter was only used when searching for a resource of an organization and sub-organization.
Here is a new patch that avoids unnecessary calculations in other cases (Kpis, PlanningElement, Parameter), when instantiating an organization to retrieve only attribute's values.

Finally, for reports, calculations are done through the PlanningElement => So no impact with the patch.

Hoping that these explanations were useful to you

Best regard

Hi,

I've included the patch, but still found many calls to calculate and set hierarchic string (for instance when looking at a project 🙁 )
So I changed the condition.
Now, it's only called when looking at Organization (it is still called 4 times, and I did notr find how to avoid it simply, but at lieat it does not have impact on any other item).