- Posts: 27
- Thank you received: 1
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
My mistake : you're right, this is good design1) You added some lines in table list, but this table is diesigned for Screen Customization plugin only.
So I'm afraid it is bad design.
I don't understand:
I just repeat what has been implemented for the visibility on the resources in the 'habilitationOther'.
The 'list' table is used to define the types of visibilities for resources (from version 6.0.0)
However, if it is a wrong way to do, can you point me to the right path.
My mistake again : I now understand what you did in this list2) Moreover you add 4 lines (OK) and change sortOrder for ids that were not created.
I think you deal with some lmines that are included in no script.
IDs exist: are those used for the visibility on resources (version 6.0.0)
Great !=> Organization screen
1) When adding Project or Resource (I like the way you integrated it), selected several items in the list to add adds only one element
(small issue, not major at all)
DONE - ADD MULTIPLE OBJECTS LINKED BY ID
Not working : unit displayed is correct, but value is still in hours2) When adding budget, work in always in day, even if unit is hours (that is correcly displayed then on budget synthesis)
Not a big issue but may be frustating (not for me as I always work with days)
DONE - WORK WITH UNIT IN PARAMETERS
OK, so if my understanding is correct daughter gap is what is left on Parent organization, not used (or at least budgeted) yet by its sub-organization.3) I don't understand how the budget part works :
What is the "daughter gap" ? it always seems equal to budget
Daughter gaps are calculated in the following way:
Budget of the Organization - sum(budget of it daughrer) (recursively)
For example, if the Organization A has to budget (for one year):
Work = 100j - cost = €1000 - expenses = €500
And it has 2 daughters (A1 and A2) which have the respective budgets (for that year):
A1 = work = 50j - cost = €500 - expense = €100
A2 = work = 30j - cost = €300 - expense= €600
A budget gap with respect to A1 and A2 (it daughters) will be:
Work = 20j - cost = €200 - expenses =-€200
1) This formula does not seem correct to me : if planning element starts year N and end year N+1, it will count same planning element on both years.How is data consolidated over years ?
The consolidations over the years are as follows: For each project the Organization and its subsidiary organizations: Filtering with PlanningElement in the following way:
/ BudgetElement period based on
// - realStartDate and realEndDate if PlanningElement.idle=1
// - validatedStartDate and validatedEndDate if PlanningElement.idle = 0
// xxxStartDate = null : No Filter >
// xxxEndDate = null : No filter <
// Else filter > and < on selected period
$whereClause .= '(
(idle=1 and
(
(isnull(realStartDate) and isnull(realEndDate)) or
(isnull(realStartDate) and year(realEndDate)=YYYY) OR
(isnull(realEndDate)) OR
(year(realStartDate)=YYYY or year(realEndDate)=YYYY)
)
) or
(idle=0 and
(
(isnull(validatedStartDate) and isnull(validatedEndDate)) or
(isnull(validatedStartDate) and year(validatedEndDate)=YYYY) OR
(isnull(validatedEndDate)) OR
(year(validatedStartDate)=YYYY or year(validatedEndDate)=YYYY)
)
)
)';
Then the budgetary elements of the projects are the sum of the corresponding data for the selected planningElements. For the realWork and the realExpense of BudgetElement, if the budget year is less than the current year, are the work.work and the expense.amount for the years <= the budget year used for the calculation of the BudgetElement.realXXXXX
Why not just consider year of validated start date : budget for projet is considered on validated start date...For instance, validated work seems to include all projects whatever the year.
For now, projects are associated with the Organization and not its annual budgets.
The calculation of the budgetary elements from the projects is based on this "unique" link.
To attach a budget to projects, should create a ProjectBudgetElement object (associated with a new table ProjectBudgetElement). In this case, the link project-organization (project.idOrganization) no longer serves much.
This is a development that I can consider if the community requests
OK, so color indicates that we are about to overrun budget.4) What is the "projects prg" ? Real VS Budget ?
Then I don't undestand how color for threshold works.
What is it an alert for ?
Projects prg is the progression of the project compared to the budget.
So organization has a budget of work in 2016 100j and 200j of work in 2017 (this works the same way for the costs and expenses).
The progress for the 2016 budget is: work (work table) of projects associated with the Organization and those associated with his daughters (recursively) with work.year <= 2016 BudgetElement.budgetWork compared with BudgetElement = 2016.
I joined 3 levels of thresholds: Alert - Warning and OK (labels are perhaps poorly chosen). If the progress of the projects (work, cost, expense) >= to the % of threshold alert then the field 'project prg' (Work, Cost, or Expense) is in red. It is alert when the budget is near to being met or exceeded (for my case, I position this threshold according to the progress in the year: 25% in Q1 - 50% in Q2 - etc.) <== indicates the budget overrun.
In the same way, I have a 'Warning' threshold which is rather here to indicate the potential to over budget. If the progress of the projects (work, cost, expense) >= to the % of threshold Warning then the field 'project prg' is orange (for my case, I positioned this threshold to Q1 = 20% - 40% = Q2 - Q3 = 70% - Q4 = 85%)
Finally, the third line (OK) identifies "good health" on budgets compared to the project.
Not really.5) I also liked the previous "synthesis for all ongoing projects".
]That is not linked to buget but gives interesting data over ongoing projects for organization.
Why did you remove it ?
Don't understand.
Maybe: The "ongoing project" is given by the budget of the current year (see rule of data bindings)
I should have a look.=> /model/BudgetElementMain__.php
1) What is this file ?
It was originally a way to see if this file was used (this is not the case). In the patch, it becomes "BudgetElementMain.php" in the original (before my contribution)
I'll have a look on how this works.2) The manager of an organization should belong to the Organization (or its parents) or not?
To fit Projeqtor design, I would say no.
If you go to project, you'll see that project manager can be selected even if not allocated to the project.
So maybe it should be the same for organization.
But we are also working on quite opposite design : automatically allocate manager to project(will come in V6.2)
It's not an issue, as manager does not get automatic access rights. He only gets them through allocations.
But to simplify, possibly you could simplify access for organisation so that only resource of organization can see the organization (if allowed to open the screen)
For now, I leave the management rule: A manager of an organization must belong to the organization. Indeed, budget management is very sensitive to the level of the companies and officials often ask to have strict rules about the rights to see, to manager. It is besides for this that I've implemented rules of visibility (the famous ' bad design').
GREAT !=> Last
1) Hard synchonization work
You worked on V6.1 that was not finalized.
So many changes done on V6.1.x (fixes) are not integrated in your code, and as you provided all files, it's a bit hard to identify fixes that were not included in your code.
So we have to integrate your code very very (very) carefully to avoid regression in V6.1.x code.
Moreover we are now working on V6.2.0 that brings many changes... And it's another hard work to integrate your work from V6.1 to V6.2.
We have to first integrate your work in working copy for branch V6.1, and checked each file to avoid regressions (this work is in progress).
Then we have to generate patch, and apply it to V6.2. Of course in is not immediate because of differences from V6.1 to V6.2 in community version (this work has not been started yet).
Then we have to re-test our own evolutions to check there were no regression (hard work to do)
I understand.
I'm now working on version 6.2 through your SVN (Revision 3929)
GREAT !!!!!2) My advise
I'm not sure we will do this twice.
So if you wish to integrate your work in community version :
a) work from latest branch; best is to get a working copy from the branch (from svn repository at sourceforge)
b) regularly integrate changes from branch to your code; if you work with a working copy, just update code. You won't be able to commit, it is normal (we want to approve all that comes in)
c) if new branch appears, switch to the new branch
d) when you're ready, just provide us with a "patch" for your code
For information we are working on Eclipse (PHP version called PDT) with svn plugin. All is easy with these tools.
Steps above can be done this way :
a) repository > checkout
b) team > synchronize > update
c) checkout new branch, export your code to new branch
d) team > create patch
This will help us much and give better chance to have your code integrate community version.
DONE - The patch is in attachment
I hope this is what you wanted
Also in attachment, the lang.xls (it poluate the patch).
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
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
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.
Ce site web utilise un certain nombre de cookies pour gérer, par exemple, les sessions utilisateurs.