[mav-adhoc]

Migration of partner_sales_abc from 19.0 to 20.0.

Tarea: https://www.adhoc.inc/odoo/project.task/76746

What changed

• __manifest__.py: version to 20.0.1.0.0, and installable back to True.
  Against origin/19.0 this is the only change the jump asked for: depends
  (["contacts"]) and auto_install are untouched.
• README.rst: the Bug Tracker link had the {project_repo} placeholder
  instead of the repo name, so it did not resolve. From 20.0 the README is the
  module description and is exported to the translation files, so the
  placeholder would end up there too.
• i18n/: .pot and es.po re-exported against 20.0, keeping the terms that
  were already translated. The module card is new in the 20.0 export: the name
  is translated and the description, which is the whole README, is left
  untranslated on purpose. "Display Name" takes the wording we fixed for the
  terms that the core translates in more than one way.

Test plan

• Installs in a clean 20.0 base with contacts and demo data.
• Verified in that base, not only in code: the field exists on res.partner
  (char), the clasificacion_abc group and the field are in the combined
  arch of base.view_partner_form, the group hangs off the single
  sales_purchases page, and the field writes and reads back.
• upgrade_code: the 10 scripts of the jump ran, 0 files modified.
• pre-commit run -a: clean.
• The module has no tests of its own, so there is no regression net here. It is
  migrated without one, with the developer's OK.
• Not tested against a real upgraded base: runbot does not run the 19 to 20
  jump yet, so this PR does not cover that either.

Known scope

In 19 the Point of Sale opened the customer form through an action that pointed
at base.view_partner_form (point_of_sale/views/res_partner_view.xml, called
from pos_store.js), so the ABC group showed up there. In 20 that action is
gone: res.partner.action_open_partner_view returns
point_of_sale.view_partner_form_pos_ui, a primary form that does not inherit
base.view_partner_form, so the ABC group is not reachable from the POS
screen. There is no error and no failing test.

This PR does not change the module for it. Covering that form would add a
point_of_sale dependency the module does not have, which would change the
bases the module installs in, and whether the cashier needs the ABC
classification is a product decision. It is asked in the task. The only
productive base with this module does not have point_of_sale installed.

[roboadhoc]

[mav-adhoc]

Adversarial review of this migration, for the reviewer. The POS one is in the
description under Known scope; these are the rest.

• The es.po label for "Display Name" changes from "Nombre para mostrar" to
  "Mostrar nombre". That is not a slip: it is the wording we fixed for the terms
  the core translates in more than one way, applied by the export tool. Flagging
  it so it is not read as an accident of the migration.
• Clasificacion ABC stays untranslated, and it is pre-existing, not from
  the jump. The msgid is already Spanish and misspelled (no accent), so the
  rule leaves msgstr empty and a Spanish user sees it as it is. Worth changing
  the label in views/partner_view.xml to English and translating it from the
  .po, as a separate change.
• What was attacked and held: that the version bump was the only change the
  jump asked for (checked against origin/19.0); that the sales_purchases
  anchor survives and the group lands in the same place (checked in a real 20.0
  base, not only in code); that no version change of the jump applies (153
  reviewed across res.partner, res.users and contacts, plus queries
  targeted at the partner form); and that no data migration script is needed.
• Limit of the review: of the base non-method version changes, the first
  60 of 342 were read one by one; the rest was closed by querying for the
  symbols this module actually touches (its own field, res.partner,
  res.users, and the contact form view), not by reading all of them.

[jcadhoc]

@roboadhoc r+ nobump rebase-ff

[roboadhoc]

Merge method set to rebase and fast-forward.