Skip to content

[17.0][OU-FIX] maintenance: keep maintenance_plan and maintenance_plan_activity#5

Open
eantones wants to merge 1 commit into
17.0from
17.0-apriori-keep-maintenance-plan
Open

[17.0][OU-FIX] maintenance: keep maintenance_plan and maintenance_plan_activity#5
eantones wants to merge 1 commit into
17.0from
17.0-apriori-keep-maintenance-plan

Conversation

@eantones

@eantones eantones commented Jul 4, 2026

Copy link
Copy Markdown
Member

The 17.0 apriori merges maintenance_plan and maintenance_plan_activity into core maintenance, following the deprecation announced in OCA/maintenance#414 (see OCA/maintenance#414 (comment)) and OCA/maintenance#468, introduced by OCA#4654 (Feb 2025).

That deprecation was later reverted: both modules were ported again and are alive and maintained on the OCA/maintenance 18.0 branch (Nov 2025 onwards, still receiving updates mid 2026).

Merging them on the 16→17 hop would destroy a live, heavily used feature set for databases that keep using the modules, and the 18.0 apriori has no entry to handle them afterwards (they would be left orphaned).

Changes

  • apriori.py: drop the maintenance_plan / maintenance_plan_activity merge entries. base_maintenance_config and maintenance_plan_employee stay — those were never ported to 17.0/18.0, their merge is still right.
  • maintenance 17.0.1.0 scripts: drop the _maintenance_plan() helpers (noteinstruction_text rename and plan → core recurrence conversion). They assume the merge happened; with the modules kept installed they would fight the modules' own schema and duplicate the recurrence logic.

Behaviour after this change

  • maintenance_plan rides the hop normally (it is ported to 17.0).
  • maintenance_plan_activity has no 17.0 port: it is carried installed without code through 17 and updates again on the 17→18 hop.

…vity

The 17.0 apriori merges maintenance_plan and maintenance_plan_activity
into core maintenance, following the deprecation announced in
OCA/maintenance#414 / OCA#468 (Feb 2025). That deprecation was later
reverted: both modules were ported again and are alive and maintained
on the 18.0 branch (Nov 2025 onwards, still updated mid 2026).

Merging them on the 16->17 hop would destroy a live, heavily used
feature set for databases that keep using the modules, and the 18.0
apriori has no entry to handle them afterwards.

- apriori: drop the maintenance_plan / maintenance_plan_activity merge
  entries. base_maintenance_config and maintenance_plan_employee stay:
  those were never ported to 17.0/18.0, their merge is still right.
- maintenance 17.0.1.0 scripts: drop the _maintenance_plan() helpers
  (note -> instruction_text rename and plan -> core recurrence
  conversion). They assume the merge happened; with the modules kept
  installed they would fight the modules' own schema and duplicate the
  recurrence logic.

maintenance_plan rides the hop normally (it is ported to 17.0).
maintenance_plan_activity has no 17.0 port: it is carried installed
without code through 17 and updates again on the 17->18 hop.
@eantones eantones added the fork-only Local policy or private-module content; never goes upstream label Jul 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

fork-only Local policy or private-module content; never goes upstream

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant