[18.0][MIG] maintenance_plan: Another Migration to 18.0

[ypapouin]

Continuation from #514, I'm reusing my comment from #514 (comment)

You can read that maintenance_plan is deprecated but merged in 17.0 #414

Currently some other modules "depends" on it (from 14.0 to 17.0):

• maintenance_inspection: https://github.com/OCA/maintenance/tree/14.0/maintenance_inspection
• maintenance_location: https://github.com/OCA/maintenance/tree/17.0/maintenance_location
• maintenance_plan_activity: https://github.com/OCA/maintenance/tree/16.0/maintenance_plan_activity
• maintenance_project_plan: https://github.com/OCA/maintenance/tree/14.0/maintenance_project_plan

For some of them (maintenance_inspection, maintenance_location), it would only require to drop references to maintenance_plan items to keep them in 18.0.

But that's not the point: the "recurrent" implementation from Odoo is javascript-only ... and its behavior has nothing to do with maintenance_plan. I think there has been a misunderstanding on this because the “advanced” features of the maintenance_plan module are much closer and more realistic to the way a maintenance workshop operates and this module should be reintroduced, that's the point of this PR.

Following are changes:

• To avoid confusion on the "recurrent" attribute, built-in fields are hidden when maintenance_plan is installed
• _compute_recurring_maintenance is always False
• The calendar view javascript attribute js_class="calendar_with_recurrence" is removed.
• The note field from maintenance.request has been dropped (use instructions fields instead)
• The note field from maintenance.plan has been replaced with the same instructions fields existing in maintenance_request since 17.0.

Remaining things to do:

• Migration script to convert note field content but how ?
• Create an intermediate wizard for the "Create request from maintenance plan" button to allow selecting a default start hour and selecting valid days of week.
• Backport this PR when merged.

[ThiagoMForgeFlow]

I’m not sure if the best way to maintain the functionalities of the child modules is to migrate this module and make Odoo’s standard functionality invisible. Perhaps we should modify the child modules so that instead of inheriting from maintenance_plan, they inherit from base_maintenance, and then refactor their functionalities. What do you think @pedrobaeza ?

[etobella]

Well, after some time struggling with the Odoo way and the maintenance plan way I think I can share my POV.

1- Odoo way is simpler, however, it works well only in controlled environments. For example, If I need to make a maintenance plan for reviews every 3 years, Odoo allows me to do it, but it creates some preventive tasks in advance that have no sense IMO.
2- Odoo way requires the creation of the first task. at some point, we added the option of autodetection of equipments. That was much better IMO.
3- Maintenance plan is complicated might be harder to configure
4- Maintenance plan allows me to create tasks in advance at the exact point I want to.

IMO, we should keep both options in the system and make maintenance_plan work in what makes sense, complex environments. It means that we shouldn't hide the odoo way, however, I would recommend to use maintenance plan if possible. About the migrations, we should need to do some stuff to avoid the execution of the migration scripts, but I have an idea of how to do it.

[pedrobaeza]

You can explain that on the CONTEXT.md file of this module.

[ThiagoMForgeFlow]

Well, after some time struggling with the Odoo way and the maintenance plan way I think I can share my POV.

1- Odoo way is simpler, however, it works well only in controlled environments. For example, If I need to make a maintenance plan for reviews every 3 years, Odoo allows me to do it, but it creates some preventive tasks in advance that have no sense IMO. 2- Odoo way requires the creation of the first task. at some point, we added the option of autodetection of equipments. That was much better IMO. 3- Maintenance plan is complicated might be harder to configure 4- Maintenance plan allows me to create tasks in advance at the exact point I want to.

IMO, we should keep both options in the system and make maintenance_plan work in what makes sense, complex environments. It means that we shouldn't hide the odoo way, however, I would recommend to use maintenance plan if possible. About the migrations, we should need to do some stuff to avoid the execution of the migration scripts, but I have an idea of how to do it.

Hi @etobella, have you been able to spend some time on the proposal for making this module’s functionalities coexist with the ones provided by Odoo?

[etobella]

@ThiagoMForgeFlow I didn't, there were no more answer on the topic, however, it might have sense IMO to restore it

[ThiagoMForgeFlow]

I agree that the module should be kept in version 18 @etobella. But I don’t think Odoo’s standard functionality should be hidden; perhaps you could add a setting to decide whether it is visible or not at the equipment or company level. What do you think @ypapouin ?

[etobella]

I do agree with your approach

[ypapouin]

I agree that the fields could easily be hidden using an option (company/equipment), but the biggest problem comes from the calendar. It uses a specific JavaScript implementation, and in fact, Odoo's entire recurring implementation is done in this calendar.

Honestly, I don't know how this option could be implemented to disable "maintenance_plan" inherited views for a specific company/equipment. (I don't really see the point of having an option to hide or show this feature, since once you install the “maintenance_plan” module, you accept that Odoo's built-in recurrent features will not be visible.)

[etobella]

I think both approaches have their own target, and might even have sense to have them together in some specific environments.

I think we shouldn't remove odoo maintenance behavior by default. If that is a problem, we can have a second module for that.

[ypapouin]

we can have a second module for that.

I'm Ok with that, I will extract every "hide/disable" view items to a specific module and add a res.config.settings to install it.
Which name for a such module ? maintenance_plan_only ?

[etobella]

Yes, it seems correct to me.

[ypapouin]

As requested, everything related to hide Odoo builtin recurrent maintenance has been moved to a new module.
The last commit adds the maintenance_plan_only module that can be enabled using a setting:

[cvinh]

Does anybody remember why the statistic data have been hidden ?

[ThiagoMForgeFlow]

Hi @cvinh, after checking the commit history I can see that it was originally added in version 12, replacing the group maintenance. Then, in the migrations for versions 13 and 17, the xpath was adjusted to match each Odoo version. However, looking at Odoo version 18, I’m not sure it still makes sense to hide these fields.

original implemenatation: 12_imp

Migration commit 13: 13_mig

Migration commit 17: 17_mig

v18 fields:

[ThiagoMForgeFlow]

Hi @etobella and @pedrobaeza What is your final opinion?

[pedrobaeza]

I let @etobella to give his opinion, as we are going to the native feature.

[etobella]

Let's proceed with it

/ocabot merge nobump

[OCA-git-bot]

This PR looks fantastic, let's merge it!
Prepared branch 18.0-ocabot-merge-pr-520-by-etobella-bump-nobump, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 4b8a8af. Thanks a lot for contributing to OCA. ❤️