[18.0][OU-ADD] mrp

[hbrunn]

/ocabot migration mrp

[MiquelRForgeFlow]

Have you checked #5034?

[MiquelRForgeFlow]

/ocabot migration mrp

[hbrunn]

Have you checked #5034?

seeing the hallucinations I consider my time too valuable to look into it in depth

*Of course I shouldn't have written "hallucination", that's the anthropomorphizing bullshit the ai bro hype machine spits out

[rvalyi]

@MiquelRForgeFlow @hbrunn for the record I admittedly just scratched the surface with 4 Gemini 2.5 pro prompts in the mentioned PR above. But I can see it got a few things right (disclaimer I didn't check deeply)...

I made this little tool to build a focused Odoo context for the AI https://github.com/akretion/akaidoo

It basically uses manifestoo to spit the models code (and migration and module-diff-analysis) of the module and all the dependent modules. So it keeps the hallucination pretty low! In these prompts I fogot to to pass the code of openupgradelib.py in the 1st prompt and apparently this is important to fully avoid hallucinations. Unlike other models Gemini has a huge context (1 millions token) and can be tested for free (for how long?) in aistudio.google.com . You can test that such "akaidoo" mrp migration prompt easily consumes 500k tokens, so the 1 million token of Gemini is the game changer here for Odoo.

BTW I don't endorse all ethics implications of AI, but I think we will have no other choice than deal with it to stay relevant. cc @pedrobaeza @etobella @sebastienbeau @renatonlima @sbidoul

[pedrobaeza]

I'm also not discarding AI in any context, but right now, I think it takes more time to ours (understood as the core OpenUpgrade developers) to do that research and experiments than to write actual working migration scripts.

[rvalyi]

I'm also not discarding AI in any context, but right now, I think it takes more time to ours (understood as the core OpenUpgrade developers) to do that research and experiments than to write actual working migration scripts.

I can imagine that. On my side it was rather to test the AI capabilities on something quite hard. And frankly I think it will be very useful on simpler modules...

Also I can assure you akaidoo and Gemini helps me a lot for the 80% of the simpler code I do daily. Yes it should still be watched carefully and corrected, but all in all I can guarantee you it's a huge productivity boost. Specially to write tests or simple customizations. At least for me.

[MiquelRForgeFlow]

Suggested change

	openupgrade.add_columns(env, [("mrp.workorder", "sequence", "integer", 100)])
	env.cr.execute(
	"""
	UPDATE mrp_workorder
	SET sequence=COALESCE(mrp_routing_workcenter.sequence, mrp_workorder.sequence)
	FROM mrp_routing_workcenter
	WHERE mrp_workorder.operation_id=mrp_routing_workcenter.id
	"""
	)
	openupgrade.add_columns(env, [("mrp.workorder", "sequence", "integer")])
	env.cr.execute(
	"""
	UPDATE mrp_workorder
	SET sequence=COALESCE(mrp_routing_workcenter.sequence, mrp_workorder.sequence)
	FROM mrp_routing_workcenter
	WHERE mrp_workorder.operation_id=mrp_routing_workcenter.id
	"""
	)
	env.cr.execute(
	"""
	SELECT COALESCE(max(sequence), 0) AS max_sequence
	FROM mrp_workorder
	WHERE sequence IS NOT NULL
	"""
	)
	max_sequence = env.cr.fetchone()[0]
	openupgrade.logged_query(
	env.cr,
	f"""
	UPDATE mrp_workorder
	SET sequence = {max_sequence} + id::int
	WHERE sequence IS NULL""",
	)

[hbrunn]

what's the point of this? In my version, work orders without operation_id are ordered by leave_id, date_start, id thanks to the default value you propose to delete. How is moving them after all orders with operation_id and enforcing an ordering by id only an improvement?

[MiquelRForgeFlow]

So, should we update them by leave_id, date_start, id? 😅

[MiquelRForgeFlow]

It think https://github.com/OCA/OpenUpgrade/blob/17.0/openupgrade_scripts/scripts/product/17.0.1.2/post-migration.py#L61 also included the ones in mrp.document. So, in fact, I think we should just check product_document.ir_attachment_id with mpr_document.ir_attachment_id and where is match set attached_on_mrp = 'bom'.

[MiquelRForgeFlow]

IA says:

[hbrunn]

how does it matter what the v17 migration did? This needs to work for just 17->18 too, so if there's anything to do, it's excluding attachments that are mrp.documents in the v17 migration.

Not sure how the word soup is helpful? We can't do anything about the field because this is set depending on the attachment being created via a bom or not, which we simply don't know, so I think defaulting to hidden is the right thing to do

[MiquelRForgeFlow]

it's excluding attachments that are mrp.documents in the v17 migration.

Exactly, just not set hidden for them.

[pedrobaeza]

Check existing comments, and everything seems to be OK.