Repository navigation
V15 v3tech upgrade - #750
Merged
Merged
Conversation
[15.0] [OU-ADD] apriori: sale_commission_formula
From now on, a journal is required for payment methods when transactions aren't splitted. If we don't set a journal in these case, the session closing won't be made properly for these methods. TT54971
…bank-payment-method-journal [15.0][OU][FIX] point_of_sale: empty journal in bank payment method
If there's more than one payment method without journal, there was a crash due to journal code duplication. This commit fixes that giving a unique journal code.
…journal_code [15.0][OU-FIX] point_of_sale: No journal code duplication
`tax_tag_invert` update logic
Removed the am.move_type = 'entry' condition from the subquery, as it
conflicts with the am.move_type IN ('out_invoice', 'in_refund',
'out_receipt') condition used in the CASE WHEN clause. Since entry is
not part of that set, the condition always evaluates to FALSE, rendering
the tax_tag_invert update ineffective.
This fix ensures that only the relevant move types are considered and
the update logic functions as intended.
[15.0][IMP] pre-commit/action: update to new version
[15.0][FIX] account: remove conflicting `am.move_type = 'entry'` condition in `tax_tag_invert` update logic
…ade_scripts [15.0][OU-FIX] payment: avoid duplicates account_payment_method_line
…e cannot be searched
…ade_scripts [15.0][OU-FIX] point_of_sale: Non-stored field pos.payment.method.typ…
…if_migration [15.0] [IMP] mail : Added elif migration from jinja to qweb
[15.0][OU-ADD] l10n_de: Nothing to do
[15.0][OU-ADD] l10n_de_skr04: Migration scripts
…ade_scripts [15.0][OU-FIX] hr_expense: if account_journal_lock_date, skip lock date
…oderation_rel-duplication-entry-error [15.0][OU-FIX] mail: avoid duplication error in mail_group_moderation_rel query
[15.0][OU-ADD] repair: Migration to 15.0
…merge_into_base [15.0][IMP] merge mass_operation_abstract into base
[15.0][OU-ADD] l10n_it remove safely xmlids
product_sale_tax_price_included is an OCA module that basically provide the new native feature 'tax_string', on product models. https://github.com/OCA/product-attribute/tree/12.0/product_sale_tax_price_included#product-sale-tax-price-included
…_included-merged-into-account-SLG [ADD] product_sale_tax_price_included: merged into 'account'.
Backport of OCA#5765 TT63118 @Tecnativa
[15.0][IMP] base: Load additional renames/merges from env.
[15.0][OU-ADD] l10n_be_edi: Nothing to do
…l_cii [15.0][OU-ADD] account_edi_ubl_cii: Nothing to do
Call cow_templates_mark_if_equal_to_upstream() in the pre-migration and cow_templates_replicate_upstream() in the end-migration. A website that enables an optional template through the Customize widget but never edits it keeps a COW copy; until now that copy was never resynced on migration, so it kept the origin arch_db and inherit_id. When a module migration re-targets which template the view inherits from, the stale copy points at the old parent and breaks rendering, as seen with website_sale_product_attribute_filter_category when website_sale moved a template between versions. cow_templates_replicate_upstream() also propagates inherit_id since OCA/openupgradelib#463. TT64160
[15.0][OU-IMP] website: reset unmodified COW templates to upstream
…ut a successor apriori.lost_modules lists the modules merged into the module they extended because they have no source any more. Before the merge, their technical noupdate records (rules, scheduled and server actions, views, menus, mail templates) are released so that the update deletes them, and the xml ids of the records of models that go with the module are detached. Business records stay.
…otification Lost in a merge of OCA (7df3a3c): the fields were renamed before the tables, so mail_notification.mail_id (still named mail_message_res_partner_needaction_rel at that point) was not renamed and mail_mail_id came empty; the rename of mail.mail notification to is_notification, marked DONE in the work file, was missing.
_migrate_mail_templates wrote report_name, subject and body_html through the ORM in the context of every installed language. That created an en_US translation of every template holding its 14.0 content, and rewrote the other translations without their module. The modules loaded afterwards then load their noupdate changes and delete the translations of their templates (delete_record_translations filters on the module): neither reached those rows, and the templates kept rendering their 14.0 content in every language, e.g. calendar.calendar_template_meeting_ reminder calling calendar.event.get_interval, removed in 15.0, or event registration templates with a t-else the conversion left without t-if. Convert the source column and each translation in SQL instead.
…ield event.event_thanks is 9.0 noupdate data that no later version ships; its reply-to reads event.event.reply_to, removed in 15.0. Databases upgraded before the 10.0 script deleted it still have it.
The 15.0 manifests of these modules declare the name they had in 14.0; without the renames an installed module would stay 'to upgrade' and its successor would not be installed. Also fix the target of viin_enterprise_marks_website (viin_hide_ent_modules_website).
The mapping of the 14.0 keys was keyed 'not satisfied' instead of 'not_satisfied': those ratings kept a key 15.0 does not know. Mapping the keys would not be right either: rating_text is stored computed from rating, and values stored by older versions with other thresholds were never recomputed (a rating of 2 kept 'not_satisfied', 15.0 computes 'ko'). Store what 15.0 computes.
…d view The end of an update deletes the views its module no longer ships under the module uninstall flag, and the core cascades to the children through inherit_children_ids, which leaves out the archived ones (e.g. an option of the website editor turned off). Their foreign key then keeps the parent from being deleted: 'violates foreign key constraint ir_ui_view_inherit_id_fkey' (website_sale.payment_footer at 17.0). Same fix as in the 10.0-13.0 forks.
From 15.0 a task without project nor parent task is private: only its assignees see it, project managers included. The ones with nobody assigned (e.g. the issues without project that became tasks in 11.0) were visible to nobody after the upgrade. Assign them to the user who created them, or to the admin when that user is not an active internal user anymore.
handle_domain_protocol prefixes the domain of each website with https://. An empty domain (12.0 stores '' for the 9.0 'localhost') became "https://", saved as "https:", which 15.0 then uses as the base of the links of the website e-mails: the customers got "https:/mail/view?access_token=..." links that open nothing. Clear empty domains instead.
…ecord
The unlink patch opened a savepoint for every obsolete record deleted by
_process_end and never released it (its name was even the same for all,
str(uuid4) instead of str(uuid4())). Each open savepoint that deletes keeps a
transactionid lock until the end of the update: a large update holds
thousands of them, and with another update running on the cluster the lock
table ran out ("out of shared memory", hop 17.0 of a real database). Release
the savepoint after the delete, and after the rollback when it fails: 200
deletions now hold 1 lock instead of 201.
… included Up to 14.0 website_crm replaced the form of the contact page with one creating an opportunity; 15.0 only fills its default values, so the migration switched the model of the page's form from mail.mail to crm.lead. Its fields kept their e-mail names: each lead got the name of the person as subject and the company and subject in its description, and the hidden e-mail recipient stayed. Rename the fields to the lead ones (contact_name, partner_name, name), drop the recipient and the custom-field marks, as the "Create an Opportunity" action of the form editor does.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
18 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.