Skip to content

[18.0][MIG] project_forecast_line: Migration to 18.0#1692

Open
solomonprabu wants to merge 79 commits intoOCA:18.0from
solomonprabu:18.0-mig-project_forecast_line
Open

[18.0][MIG] project_forecast_line: Migration to 18.0#1692
solomonprabu wants to merge 79 commits intoOCA:18.0from
solomonprabu:18.0-mig-project_forecast_line

Conversation

@solomonprabu
Copy link
Copy Markdown

[Migrated] project_forecast_line to Odoo 18.0.

Note on Views:
I kept the inheritance targeting project.project_project_stage_view_tree. Even though Odoo 18 is moving toward _view_list naming, the base project module still uses the _view_tree ID for this record, so I've used that to avoid any reference errors.

yankinmax and others added 30 commits March 10, 2026 15:24
in some cases, we could have capacity consumed by a task which was not matching
a work capacity line in the period because of a faulty optimisation we were making
which skipped the creation of lines with a capacity of 0 -> then we had no line on which
to compute the negative consolidated capacity.

We remove the optimisation to fix this case and show the problematic periods
in the consolidated capacity graphs
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: project-15.0/project-15.0-project_forecast_line
Translate-URL: https://translation.odoo-community.org/projects/project-15-0/project-15-0-project_forecast_line/
During some operations, forecast lines are deleted and recreated. This
can lead to some hr.employee.forecast.role lines being deleted which
leaves the forecast lines on the same period without a related document
to store the consolidated capacity. Normally that line is recreated
shortly afterwards but the creation does not recompute the link between
the parent-less lines and the new one. This patches forces the
recomputation when new lines are created.
The idea is to have two consolidated forecast fields, instead of setting.
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: project-15.0/project-15.0-project_forecast_line
Translate-URL: https://translation.odoo-community.org/projects/project-15-0/project-15-0-project_forecast_line/
Add computed fields to written fields to trigger forecast lines update
Add hook for several UoM hours/days conversion
@luisDIXMIT
Copy link
Copy Markdown

Test are failing, review the use of flush_model in tests.

@solomonprabu solomonprabu mentioned this pull request Mar 17, 2026
44 tasks
@solomonprabu
Copy link
Copy Markdown
Author

Test are failing, review the use of flush_model in tests.

Tests are succeeding now!

@luisDIXMIT
Copy link
Copy Markdown

Test are failing, review the use of flush_model in tests.

Tests are succeeding now!

Nice, can you squash the commits into a single migration commit? Or, if you prefer, keep one migration commit and one improvement commit. I see too many commits, let’s keep the commit history simple.

@tarteo
Copy link
Copy Markdown
Member

tarteo commented Mar 20, 2026

Can you take a look at these comments here and apply them when necessary #1247

@solomonprabu
Copy link
Copy Markdown
Author

Can you take a look at these comments here and apply them when necessary #1247

Looking into it, will let you know once it is fixed.

@solomonprabu
Copy link
Copy Markdown
Author

Test are failing, review the use of flush_model in tests.

Tests are succeeding now!

Nice, can you squash the commits into a single migration commit? Or, if you prefer, keep one migration commit and one improvement commit. I see too many commits, let’s keep the commit history simple.

I totally agree with you on this! will squash the commits once I'm done.

@solomonprabu
Copy link
Copy Markdown
Author

Can you take a look at these comments here and apply them when necessary #1247

  1. Fixed project task view
image
  1. Fixed res.config.settings view
image
  1. regarding [[16.0][MIG] project_forecast_line] #1247 I do not get the error on changing stages for the task.

@solomonprabu
Copy link
Copy Markdown
Author

@tarteo

Is it better to use existing fields from project_timeline? #1247 (comment)

Regarding this, I had the same opinion on this. For now I do not see any complications on using the fields from project_timeline Yet I feel it is better to do the changes and run tests on both the modules locally to ensure that they are working as intended and do not interrupt any functions.

This could be time consuming though, if something falls apart!

@solomonprabu
Copy link
Copy Markdown
Author

@tarteo Also using the field from project_timeline will create a installation dependency on project_timeline and web_timeline for project_forecast_timeline to be installed.

@solomonprabu
Copy link
Copy Markdown
Author

@tarteo I have tested the files locally after replacing the fields from project_timeline. The tests pass. Let me if we're moving with these fields, depending on your decision I will push the code here.

Copy link
Copy Markdown
Member

@tarteo tarteo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@solomonprabu Thanks for the fixes! The date fields can also be addressed later, it is out of scope for this migration PR.

IMO the ideal situation would be:

  • A module project_date that just introduces the fields
  • project_timeline depends on project_date (reusing those fields instead of adding new ones)
  • project_forecast_line depends on project_date (reusing those fields instead of adding new ones)

This way we avoid introducing a dependency on web_timeline, while still having any task planned using the forecast module reflected in the the project task timeline view.

@solomonprabu
Copy link
Copy Markdown
Author

solomonprabu commented Mar 26, 2026

@solomonprabu Thanks for the fixes! The date fields can also be addressed later, it is out of scope for this migration PR.

IMO the ideal situation would be:

* A module `project_date` that just introduces the fields

* `project_timeline` depends on `project_date` (reusing those fields instead of adding new ones)

* `project_forecast_line` depends on `project_date` (reusing those fields instead of adding new ones)

This way we avoid introducing a dependency on web_timeline, while still having any task planned using the forecast module reflected in the the project task timeline view.

@tarteo
Thanks for the validation! I'm interested in your proposed idea and I believe it would be the cleanest possible way to handle this.

🙌 Cheers for the PR approval and have a good weekend :)

@solomonprabu solomonprabu force-pushed the 18.0-mig-project_forecast_line branch from 8ba64ac to 8ac84f3 Compare March 26, 2026 05:22
@tarteo
Copy link
Copy Markdown
Member

tarteo commented Mar 26, 2026

When planning a task, it is not reflected in the forecast:
image

image

@solomonprabu
Copy link
Copy Markdown
Author

When planning a task, it is not reflected in the forecast: image
image

@tarteo The issue is in here, the _write method in project_task.py#L56-L62 is not being called or executed. Moving this method to ORM write method fixes it.

But that makes the forecast_recomputation_trigger field and its _compute method redundant.

@solomonprabu
Copy link
Copy Markdown
Author

@tarteo The bug is now fixed!

@solomonprabu
Copy link
Copy Markdown
Author

@luisDIXMIT All checks have passed.

@luisDIXMIT
Copy link
Copy Markdown

Nice, but could you squash the commits? It's too large. It should be squashed into a single migration commit, or perhaps into two commits if there are fixes or improvements outside the migration scope.

[FIX] Demo data xml to fix installation errors and warnings

[FIX] Demo data xml to fix installation errors and warnings

[FIX] Typo
[FIX] Typo

[FIX] Demo data xml to fix installation errors and warnings

[FIX] fixed test case error, mis-calculations and xml errors

[ADD] Improved test coverage and improved onchange method

[FIX] Demo data xml to fix installation errors and warnings

[FIX] Typo

[FIX] fixed test case error, mis-calculations and xml errors

[FIX] Pre commit errors

[UPDATE] updated missing variable

[UPDATE] updated missing variables

[FIX] Typo

[FIX] implemented feedbacks from PR OCA#1247

[UPDATE] Introduced new test case

[DEL] removed duplicate code

[FIX] reverting field changes to fix tests

[UPDATE] Changing logger warning to info.

 To maintain clean logs and for pipeline to succeed, as warnings in log stops the container from succeeding

[ADD] Added new testcases to improve code coverage

[FIX] incorrect date object

[UPDATE] fixing test method

[ADD] Added test cases and refactored tests

[FIX] fixing parameters

[ADD] Hr Leave test coverage

[FIX] Pre commit fix

[FIX] logger warning to info

[Add] Code coverage improvement

[Add] Code coverage improvement for Hr Leave

[UPDATE] Update _write method with _write_multi. Odoo18 changes
@solomonprabu solomonprabu force-pushed the 18.0-mig-project_forecast_line branch from e92d97e to 8c5860a Compare March 31, 2026 09:32
@solomonprabu
Copy link
Copy Markdown
Author

Nice, but could you squash the commits? It's too large. It should be squashed into a single migration commit, or perhaps into two commits if there are fixes or improvements outside the migration scope.

Squashed! Ready to merge?

Copy link
Copy Markdown

@luisDIXMIT luisDIXMIT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review, good work, some minor comments.

Copy link
Copy Markdown

@luisDIXMIT luisDIXMIT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good work, LGTM, I won't block the PR.

@OCA-git-bot
Copy link
Copy Markdown
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

@solomonprabu
Copy link
Copy Markdown
Author

@sebastienbeau PR is ready to be merged!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.