u/wz2b

I’m have a custom CRM workflow in Odoo and I’m trying to find the most Odoo-native way to implement a “soft warning” on `crm.lead` stage changes.

I have some dynamic requirements (checklists) associated with opportunities and stages. When a user tries to move an opportunity out of its current stage before completing the requirements for that stage, I would like to show a confirmation dialog along the lines of:

> You have not completed all requirements for the current stage. Do you want to continue moving this opportunity anyway?

The desired behavior is:

- If the user clicks **Cancel**, the stage change is reverted.

- If the user clicks **Continue**, the stage change proceeds.

- I do **not** want to completely block the save in all cases.

- I want this to apply when changing `stage_id` on `crm.lead`, ideally including normal form usage and possibly kanban stage changes.

The approaches I’ve considered:

1. `@api.onchange("stage_id")`

   This can detect the stage change and return a warning, but it does not seem to provide a clean “Continue / Cancel” interaction. I could revert the field in the onchange, but that is more of a hard reset than a confirmation flow.

2. Override `write()`

   This is good for hard enforcement because I can raise a `UserError`, but that does not give the user an option to proceed. I could use context flags to bypass the check, but then I still need a clean UI path to set that context after confirmation.

3. Custom button / wizard

   I could replace free stage changes with a custom “Move Stage” action that opens a wizard when requirements are incomplete. This seems more controllable, but it feels heavier and may not integrate well with normal CRM kanban dragging (which is what people tend to use)

4. Custom JS patch

   I suspect the exact behavior may require patching the CRM form/kanban stage-change behavior in JavaScript, calling a server method to check requirements, and then showing a confirmation dialog before allowing the write. I’m trying to understand whether this is the expected approach or overkill. It seems like too much.

Is there an Odoo-recommended pattern for this kind of “soft validation with user confirmation” on field changes?

In other words: not a hard validation error, but a conditional “Are you sure?” dialog before allowing a `stage_id` change on `crm.lead`.

I’m especially interested in how people handle this in Odoo 17/18 with the modern web client / OWL framework. I’m hoping to avoid a large or brittle custom OWL patch/component if possible. This is meant to be a lightweight workflow nudge, not a full custom stage-change mechanism. Has anyone implemented something like this in a reasonably maintainable way?

Is anybody familiar with the PowerLogic CM200 series power meters? Ancient things ... gigantic 7-segment LED display. I'm pretty sure it speaks Sy/MAX but I really can't get it to answer me, not even with DLE ENQ. I don't suppose there are compatible PC tools out there just to diagnose if the meter still communicates?

One other brief tale I forgot to mention about my 17 to 18 migration. When I brought up the odoo 18 instance I couldn't log in. The UI took me straight to the database configuration wizard, and the console generated a bunch of errors about not being able to create a session. I figured out that Odoo no longer had write access to /var/lib/odoo/.local.

The cause was that for some mysterious reason the uid changed. I have to assume this was a docker packaging error - there's no way someone would do this intentionally (it serves no purpose that I can see, and it causes pain).

root@dev:/home/cep# docker run --rm -it odoo:17.0 id -a odoo
uid=101(odoo) gid=101(odoo) groups=101(odoo)

root@dev:/home/cep# docker run --rm -it odoo:18.0 id -a odoo
uid=100(odoo) gid=101(odoo) groups=101(odoo)

My Odoo 17 → 18 upgrade went pretty well overall.

I hit two main categories of problems.

The first was in my own custom modules. The obvious one was the well-known <tree> → <list> change in views and XPath expressions. I also had a few view customizations around invisible attributes that did not survive cleanly. In particular, I had some old inherited-view tricks that were no longer valid in 18. Most of them had to do with un-hiding fields that Odoo hides by default - for example a crm.lead can be a "Lead" or an "Opportunity" and if it's one or the other certain fields disappear. We don't want that. The unhiding approach I used in 17 didn't work in 18 - my fault, and it was not too hard to fix once I found it.

The bigger lesson for me: I am now very enthusiastic about splitting custom addons into two layers:

• a _data addon with only models, fields, relationships, very high level security, and persistent business logic
• an _app addon with views, menus, reports, dashboards, and other UI glue

If I had done that from the start, I could have migrated the stable data/model layer first and deferred most of the view breakage until after the database migration. Lesson very much learned.

The second problem was an old Slack connector addon from 17 that is not available in 18. I decided to remove it before migrating, but it did not remove cleanly - it left behind a surprising amount of debris in the database: cron jobs, server actions, XML IDs, model metadata, fields, and even physical tables/columns. After migration, some of those leftovers caused warnings and errors in the Odoo log, including a scheduled action still trying to call Slack synchronization code that no longer existed.

I eventually cleaned it up manually with SQL, but it felt dangerous and was not fun. So if you ever installed that Slack connector, be careful before migrating. Check for leftover crons, server actions, ir_model_data, ir_model_fields, views, and physical tables/columns.

The Slack integration was actually useful for me because it helped keep an eye on CRM-related activity, so I am going to miss the functionality. But if there is ever a new version, I am going to inspect it pretty closely before installing it again.

Overall, though: OpenUpgrade did a lot of the hard work. My main pain came from custom views and old addon debris, not from the core migration itself.

I’m migrating an Odoo 17 database to Odoo 18 and I have a few custom addons that are causing migration grief. I’m using OpenUpgrade for the database migration, then updating my custom modules one at a time.

The first obvious issue is the Odoo 18 change from `<tree>` to `<list>`. That part is straightforward enough mechanically, but I’m expecting that once I fix those, I’ll uncover the next 100 issues.

The bigger concern is with custom views that inherit/extend standard Odoo views. Those only work if the parent views still have the same structure, and across versions that is obviously not guaranteed. Menu placement has also always been a bit fragile for me because it depends on finding the right parent menu/action/XML ID to latch onto.

To reduce this pain in the future, I’m considering splitting my custom addons into separate layers:

• a data/model addon that defines models, fields, security, and any durable database structures
• a UI/app addon that defines menus, actions, views, reports, dashboards, etc.

That way, during future migrations, the data/model layer can migrate first, and the UI layer can be disabled or fixed independently without breaking the underlying data.

I tried to find a good migration guide for this specific situation, but didn’t find much beyond the usual module migration notes. For people who have done Odoo major-version migrations with custom addons:

1. Is splitting model/data changes from views/reports/menus a common or recommended strategy? (I use two addons - one is not an "app" but it depends on the other, which has all the model extensions and new models
2. For Odoo 18 specifically, is `tree → list` mostly just a mechanical XML change, or are there deeper gotchas? I'm sure there's more, I'm just hoping someone has some "look out for" style tips
3. How do you usually handle inherited views when the parent Odoo view structure changes?
4. Any advice for making menu/action placement less fragile across upgrades?
5. Is there a better migration workflow than “fix the first error, rerun `-u module`, repeat until done”?

I’m not looking for anyone to solve my module problems. In the grand scheme of things, these issues are (so far) pretty small - 27 view mods, most of them very simple. I'm mostly trying to learn the sane migration discipline here before I create more future pain for myself. I need to script this to some degree because it's going to take me some time to do the changes, and when I'm ready I'll certainly have to start again from the beginning with a fresh odoo 17 backup database. For the moment I'm just trying to set up an odoo 18 test and qa environment; the real migration will come later (rinse, lather, repeat, ...)