[16.0][IMP] edi_storage_oca: Add script to migrate to v16

[QuocDuong1306]

Context:

• Assume that storage_backend will still be installed in the old db and that we simply have to create the matching fs.storage records w/ their conf leaving the old storage.backend records untouched.

Notes:

• Put this script to 16.0.1.0.0 because of changing storage_backend to fs_storage, if we put it to the later versions, the storages in backends have been changed, so can't link to the mapping records in fs.storage

• storage_backend_ftp and storage_backend_s3 have not been migrated to 16.0 (and should not)

• storage_backend depends on server_environment

  • we just need to create a fs_storage, and link it with the edi_backend
  • the rest (host/port/credentials) will come from the environment

  cc @simahawk @etobella

[etobella]

@luisDIXMIT

[simahawk]

@etobella would you be able to test this in real life?

[simahawk]

• storage_backend_ftp and storage_backend_s3 have not been migrated to 16.0 (and should not)

FTR I doubt we should not 😉

[etobella]

• the rest (host/port/credentials) will come from the environment

That is not true. We could define information directly on the storage. this information needs to be ported too

[etobella]

I think you don't need this verificatiion. If you are in this script, you come from 15, so storage_backend is installed

[etobella]

I think we should only transform the backends that come from edi.backends. Probably we need to add some SQL here, but it is the cleaner option IMO

[etobella]

In order to avoid the create new column, change column to old and new to current you can do:

        _column_renames = {
            "edi_backend": [
                ("storage_id", False),            ],
        }
        openupgrade.rename_columns(env.cr, _column_renames)
        create_column(env.cr, "edi_backend", "storage_id", "int4")

The old field will have the following name: openupgrade.get_legacy_name("storage_id")

[nilshamerlinck]

Hi @simahawk precision about that point:

storage_backend_ftp and storage_backend_s3 have not been migrated to 16.0 (and should not)

FTR I doubt we should not

of course some people might decide to migrate them, like storage_backend_sftp was
but what we meant here is that fs_storage is now the preferred way
and as concretely these modules are not available in 16.0, we needed a small trick to allow the migration script to manipulate storage.backend of various types, see here: