[DOC-ADD] Use Case : mapping values

[legalsylvain]

Quite trivial use case about openupgrade.map_values function.

[legalsylvain]

CC : @etobella, @bguillot, @hbrunn, @StefanRijnhart, @pedrobaeza

[pedrobaeza]

Suggested change

	This is the case, when there are just one or more new options available in the recent version
	AND when no option is disappeared.
	This is the case, when there are just one or more new options available in the recent version that are new features
	AND when no option is disappeared. Just be sure that none of the old cases in previous version may match one of the new selection values. If it's the case, you will need to do perform a query selecting and updating the proper records that match this criteria.

and I would search for one example of this type.

[legalsylvain]

Ow I get it.
I have never been confronted with this use case. Do you ?

[pedrobaeza]

I think this one can be an example:

OpenUpgrade/openupgrade_scripts/scripts/hr_holidays/15.0.1.5/upgrade_analysis_work.txt

Line 107 in 0d918b5

# DONE: pre-migration: old values been saved. 'officer' if allocation_type = 'fixed_allocation', 'set' if allocation_type = 'fixed', else 'no'

OpenUpgrade/openupgrade_scripts/scripts/hr_holidays/15.0.1.5/pre-migration.py

Line 71 in 0d918b5

def refill_hr_leave_type_allocation_validation_type(env):

[legalsylvain]

Thanks !

I don't use HR, so I didn't know about this mapping.

I'm not sure adding such text you propose will help people. It's a very weird case :

If I understand correctly :
V14 :

• allocation_type(['fixed', 'fixed_allocation', 'no'])
• allocation_validation_type (['both', 'hr', 'manager'])

V15 :

• allocation_validation_type ['no', 'officer', 'set'], based on the V14 allocation_type.

For me, in fact, it's a :

• rename_fields : (allocation_type -> allocation_validation_type)
• a classic mapping value : (fixed_allocation -> officer // fixed --> set // no -> no)

But all the information present in the allocation_validation_type V14 fields are lost. (Or did I missed something ?)

The "problem" here is that odoo rename allocation_type to allocation_validation_type that was existing and that create confusion.

[pedrobaeza]

Yes, my example is not very straight. This one should be:

OpenUpgrade/openupgrade_scripts/scripts/account/14.0.1.1/upgrade_analysis_work.txt

Line 53 in 34507b3

# DONE: post-migration: new 'posted' state. the workflow is 'open' (draft) -> 'posted' -> 'confirm'. Marked as 'posted' the 'confirm' entries which have unreconciled lines.

https://github.com/OCA/OpenUpgrade/blob/34507b317ee6f4a53bdcbf249bd2e91659029931/openupgrade_scripts/scripts/account/14.0.1.1/post-migration.py#LL316C22-L316C22

[legalsylvain]

Thanks ! I get it !
i'll read the code and add a text for this interesting use case.

[pedrobaeza]

We can talk here about another general case that a state is unfolded into 2 in the new version, and we can move some of the records to this new value if certain criteria is met.

[legalsylvain]

We can talk here about another general case that a state is unfolded into 2 in the new version, and we can move some of the records to this new value if certain criteria is met.

This is the same situation as in the example with account.bank.statement you mentioned, isn't it? (i.e. between v13 and v14 "confirmed" splitted "posted" and "confirmed")

I make changes / additions you can release here :
https://github.com/OCA/OpenUpgrade/pull/3845/files#diff-6f6f096f2fadc47bc0c7fbcaff30510b6f811abe6f60594ecd56cd8c8eafa7a7R175-R201

what do you think of it?

regards.

[pedrobaeza]

Yes, it was just a rephrasing of the use case I mentioned.

[jcdrubay]

This "Use Case" documentation is great!

Later:

• in the openupgrade_analysis.txt file generated automatically might even include a link to these :)
• the migration effort for OpenUpgrade scripts could be computed based on these standard Use Cases, maybe in OCA CM :p https://oca-cm-15.komit.link/odoo-module-version?repository=odoo/odoo&module=account&version=16.0

[legalsylvain]

This "Use Case" documentation is great!

Thanks !

in the openupgrade_analysis.txt file generated automatically might even include a link to these :)

Could be great. however, openupgrade documentation url changed several times since 10 years. if we set an url in all the openupgrade_analysis.txt. I'm afraid I'll end up in a situation where a lot of files, on several branches, link to 404 page or worse, obsolete documentation., and that requires some maintenance, which we may forget to do ... I hesitate between the pros and cons!

the migration effort for OpenUpgrade scripts could be computed based on these standard Use Cases, maybe in OCA CM :p https://oca-cm-15.komit.link/odoo-module-version?repository=odoo/odoo&module=account&version=16.0

I think there are a lot of things I didn't understand when you presented your proposal a few months ago. Would you be available to discuss by phone / video. If yes, send me an email.

Regards.

[legalsylvain]

@pedrobaeza : could you update your review when you have a little time?
I think I've addressed all your comments.