Merge from upstream 17 20260911 01 - #1277
Open
royle-vietnam wants to merge 135 commits into
Open
royle-vietnam wants to merge 135 commits into
royle-vietnam wants to merge 135 commits into
Conversation
The selection options for l10n_id_coretax_add_info_07/08 and l10n_id_coretax_facility_info_07 were swapped: the "additional information" fields showed facility stamp text and vice versa. Also add the UoM codes and new kode faktur 07 additional info/facility stamp options published by DJP on 2026-01-26. task-6434742 closes odoo#281096 Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
…workaround Steps to Reproduce the Error (Odoo SaaS 19.2): 1. Install l10n_gcc_invoice localization & Accounting 2. Activate Arabic language (ar_001) and add Default Terms and Conditions in Settings > Configuration > Customer Invoices > Default Terms and Conditions 3. Create invoice with ar_001 partner 4. Confirm the invoice 5. Try to create credit note → Error: KeyError: 'en_US' Root Cause: The _load_narration_translation() workaround reads raw invoice_terms from DB and injects the entire JSONB dict directly into cache, bypassing ORM field conversion. When Odoo 19.2's improved ORM conversion runs, it creates nested JSON in narration instead of a flat structure. Timeline: - bedf1cb: Workaround added to prevent T&C duplication in preview - 75f050b: Root cause fixed in report template (conditional display) → Made _load_narration_translation() redundant - 4e41565: Odoo 19.2 improved ORM conversion → Now conflicts with the redundant workaround, causing nested JSON How It Breaks: 1. Invoice creation: _load_narration_translation() injects raw dict into cache 2. ORM writes: nested JSON stored: {ar_001: {en_US: ., ar_001: Arabic}} 3. Credit note creation: copy_translations() expects flat structure → Crashes: KeyError: 'en_US' Why It's Safe to Remove: Report template already prevents T&C duplication (commit 75f050b). Removing the workaround restores proper credit note creation without breaking T&C display. Changes: - Remove moves._load_narration_translation() in create() - Remove out self.filtered('id')._load_narration_translation() in _compute_narration() closes odoo#273617 X-original-commit: 19669f7 Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
Steps to reproduce: - Set the browser timezone ahead of UTC, where the local date has rolled over but the UTC one has not, e.g. Australia/Perth (UTC+8) between 00:00 and 08:00 local. - On a sales order, schedule an activity due today's local date. - Apply the "Today Activities" filter on the Sales Orders list view. Issue: The order is not returned; it shows up under "Future Activities" until the UTC date catches up, while the chatter labels the same activity "Today". Cause of the issue: The filter compares my_activity_date_deadline, a Date field, against context_today(), which returns PyDate.today(), built by PyDate.convertDate() and switched to the UTC getters in e048bb5, undoing the fix of the same symptom in 41d135d for PyDate. That is right for PyDateTime, compared against Datetime fields stored in UTC, but a Date is a calendar day, not an instant: making it UTC does not remove the dependency on the user's location, it only gives every user Greenwich's day instead of their own. Fix: Restore the local getters in PyDate.convertDate, reverting that method to its pre-e048bb5087784720145916cfc18372617123e7bd behaviour. opw-6415985 closes odoo#278761 Signed-off-by: Bastien Pierre (ipb) <ipb@odoo.com>
An old refactor left some data around that are in conflict with other records for the same model. closes odoo#281276 Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
The right value often comes from the user and the search implementation may not handle 'any' properly, however 'in' is nearly always implemented. For most cases, transform 'any' into a 'in' before calling Field.search. task-6446206 closes odoo#280362 Signed-off-by: Raphael Collet <rco@odoo.com>
closes odoo#281391 Signed-off-by: John Laterre (jol) <jol@odoo.com>
l10n_fr_pdp's settings view inherits account_peppol and uses peppol_use_parent_company in `invisible`s. The node for that field is provided by account_peppol, but it was only added to account_peppol settings view in 0ab1e03. On a database whose account_peppol was not updated after this commit, installing l10n_fr_pdp does not upgrade account_peppol, so this invisible references a field that doesn't exist in the view, so tb at install ``` Error while validating view near: <form string="Settings" class="oe_form_configuration" js_class="base_settings"> <field name="is_root_company" invisible="1"/> <app data-string="General Settings" string="General Settings" name="general_settings" logo="/base/static/description/settings.png"> Field 'peppol_use_parent_company' used in modifier 'invisible' (peppol_use_parent_company or account_peppol_proxy_state not in ('sender', 'pending', 'active')) must be present in view but is missing. View error context: {'file': '/home/odoo/src/odoo/17.0/addons/l10n_fr_pdp/views/res_config_settings_views.xml', 'line': 1, 'name': 'res.config.settings.view.form.inherit.proxy.user', 'view': ir.ui.view(2640,), 'view.model': 'res.config.settings', 'view.parent': ir.ui.view(1604,), 'xmlid': 'res_config_settings_view_form'} ``` closes odoo#281520 Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
We still have cases of people being confused by the fact that they send their invoices, reset it to draft, change something, then re-sending. Of course, the re-sending does not send on peppol, as it's already sent. It's more confusing than anything else. Prevent it if they're sent and not in error task-6459869 closes odoo#281525 Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Part-of: odoo#276648 Signed-off-by: Krzysztof Magusiak (krma) <krma@odoo.com>
Odoo intentionally leaves Pillow's WebP decoder unloaded, but URL imports used Pillow directly to validate image dimensions. This rejected valid WebP images even though Odoo's image fields support them. Validate downloaded images with ImageProcess so WebP and other formats share the same identity and IMAGE_MAX_RESOLUTION checks without enabling the decoder or duplicating format-specific logic. closes odoo#276648 Signed-off-by: Krzysztof Magusiak (krma) <krma@odoo.com>
Steps to reproduce: - Create an invoice in a Saudi company (currency SAR) - Process it with ZATCA and review the generated XML file - ZATCA reports a validation error/notification for duplicate tax values, because the XML contains two cac:TaxTotal elements holding the same amount and currency Cause of the issue: _l10n_sa_get_additional_tax_total_vals always appended a second TaxTotal node regardless of the invoice's currency. this extra node is only valid when the invoice currency differs from the company's accounting currency (SAR). Since most Saudi invoices are issued in SAR (same as the company currency), the second TaxTotal was an exact duplicate of the first one's total amount. Solution: Only add the additional TaxTotal node when the invoice currency differs from the company currency opw-6409881 closes odoo#279929 Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
When apply for a job, if the partner is provided, the other information is not required. Task-6449336
…amped closes odoo#269458 Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Issue: When a company is not connected to the French Electronic Invoicing PDP proxy, the generated XML is missing required notes: `PMT`, `PMD` and `AAB` These notes are required by Factur-X rule `BR-FR-05/BT-22` and their absence causes validation errors on the FNFE validator Cause: `_l10n_fr_pdp_get_default_notes` only added the notes when the company was using a PDP proxy type Non-PDP users sending invoices via other means were excluded, which contradicts the French e-invoicing requirements Steps to reproduce: - Install `l10n_fr_pdp` and switch to the FR company - In Settings, ensure French Electronic Invoicing is not activated - Create and confirm an invoice (any line with tax) - Send the invoice and open the generated XML Before the fix, the `PMT`, `PMD` and `AAB` notes are missing Activating French Electronic Invoicing would include them opw-6392262 closes odoo#279966 Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
When this happens, simply delegate to the origin record. opw-6425802 closes odoo#281756 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Automatically update the ruff config to the latest version generated on runbot closes odoo#281966 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
…pute
## Issue
When filtering projects using the "Timesheets >100%" filter, some projects
with negative remaining hours (and with their `is_project_overtime` field
set to True) won't be displayed, even though their expected hours are
completed.
This happens with projects which have tasks set to the "Done" or
"Cancelled" state. The timesheets entries in those tasks are not taken
into account when searching using the "Timesheets >100%" filter.
## Steps to reproduce
1. Install *Task Logs* (`hr_timesheet`)
2. Create a Project P (with Timehseets enabled)
3. Set the allocated hours of the project to 3:00 (3 hours)
4. Create two tasks:
- T1: State "In progress", and one timesheet entry of 2:00 (2 hours)
- T2: State "Done", and one timesheet entry of 2:00 (2 hours)
5. Back to the project view, set the filter to "Timesheets >100%"
6. **Project P is not shown, even though the total time spent on the
project is 4 hours, completing the allocated hours set on the project.**
## Cause
The `_search_is_project_overtime` method filters out the tasks in "closed"
states (Done/Cancelled) when computing the amount of time spent on the project.
https://github.com/odoo/odoo/blob/126b5bdd1e85771549198976f8570cd2ff167608/addons/hr_timesheet/models/project_project.py#L103-L114
This does not match with the behavior of the `_compute_is_project_overtime`,
which does not take into account the state of the tasks to determine the
value of the field:
https://github.com/odoo/odoo/blob/126b5bdd1e85771549198976f8570cd2ff167608/addons/hr_timesheet/models/project_project.py#L85-L94
This leads to a confusing behavior, where a project can have its
`is_project_overtime` field set to True, but will still not be shown when
using the "Timsheets >100%", even though that filter is defined as
`[("is_project_overtime", "=", True)]`.
The compute method was updated by odoo@d425282,
but the related search method was left unchanged, leading to this slight
incoherence between the two methods.
opw-6422173
closes odoo#281997
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Issue before this commit: When generating an electronic invoice (e.g., ZUGFeRD/Factur-X) with a 0% tax from a non-EEA supplier (e.g., Switzerland) to an EEA customer (e.g., Germany), the XML tax <ram:CategoryCode> is incorrectly set to 'E' (Exempt) instead of 'G' (Export). Steps to reproduce the issue: 1. Download Accounting and l10n_ch 2. Set the VAT for the CH company 3. Create an invoice for a German customer with 0% tax setted (for which you have to set as electronic invoicing the ZUGFeRD template into the Accounting tab of his contact) 4. Send it and see that the tag <ram:CategoryCode> is setted as E instead of G Cause of the issue: The logic assigning the 'G' and 'K' tax category codes was only triggered if the supplier was located within the EEA. If the supplier was outside the EEA, the code bypassed this block entirely and fell back to the default 'E' code for 0% taxes. Reason to introduce the fix: Update the condition to trigger when either the supplier or the customer is in the EEA. This ensures that cross-border transactions involving at least one EEA party correctly evaluate and apply the 'G' (Export outside the EU) category code. Also the case supplier not in eea with VAT filled in + customer in eea + RC tax with amount != 0 is fixed now (letter G reported instead of S). opw-6407399 closes odoo#281245 Signed-off-by: Thomas Becquevort (thbe) <thbe@odoo.com>
The `create_calendar_meeting` field on `hr.leave.type` allows users to choose if leave requests created with a given time off type generate a corresponding entry in the Calendar app. However, this field was not displayed on the form view. This commit adds `create_calendar_meeting` to the `hr.leave.type` form view inside the configuration section, along with dedicated help text explaining its behavior. closes odoo#280593 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Follow-up to the backport of the response module in commit 9ca317f . Currently (on 17.0) we do not send the supported identifiers when registering. So i.e. not the response service This is fixed in this commit. The IAP side had to be adapted so it was omitted in the original commit (since the main purpose was to backport PDP). task-None closes odoo#279650 Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Steps to reproduce:
- Activate a Spanish language (e.g. es_MX) and use it as report
language.
- Post a customer invoice in MXN totalling e.g. $2,301,439.88.
- Print the invoice PDF ("Importe total con letra").
Current behavior:
"... TRESCIENTOS UNO MIL CUATROCIENTOS ..."
Expected behavior:
"... TRESCIENTOS UN MIL CUATROCIENTOS ..."
Cause of the issue:
num2words applies the Spanish apocope only in its currency mode,
never in to_cardinal(). Odoo renders the plain cardinal and appends
the currency label itself, so that path is never taken.
Fix:
Apocopate in to_cardinal(), for es, es_CO and es_VE, before "mil"
and "millón"/"billón"/... Those nouns are always masculine, so the
form is known. A final "uno" is left alone: it agrees with the
currency label appended by amount_to_text ("mil un pesos" but "mil
una libras"), whose gender is not knowable here.
opw-6375677
closes odoo#277919
Signed-off-by: Arnaud Sibille (arsi) <arsi@odoo.com>
the field l10n_sa_edi_is_production was introduced in 19.0, so it was never supposed to survive the backport to 17.0 closes odoo#282232 Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Calling `/shop/payment/validate` as a portal user with an empty cart confirms the empty sale order. Steps to reproduce: - Sign in as a portal user. - Add a product to the cart. - Remove the product. - Go to `/shop/payment/validate`. - The empty sale order is confirmed. opw-6430637 closes odoo#280924 Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>
When loading the registry, borrow the request to avoid having using the cursor linked to it. Failing use case before the fix: install base odoo, in the web interface, activate and switch to a new language then install website. The installation will hang if the stable cache is invalidated because the installation may call `_` which will fallback to the request's language - reading the table from the request's cursor - while the installation tries to update the same of that same table in another cursor. Backport of odoo#281797 closes odoo#281798 Signed-off-by: Krzysztof Magusiak (krma) <krma@odoo.com>
**Steps to reproduce:** 1. Install Accounting 2. Import a new invoice with more than 1000 lines (xlsx file found in ticket attachments) 3. Test the imported records **Issue:** - `RecursionError: maximum recursion depth exceeded`. **Cause:** - In a previous commit (3e32d7b) aimed at fixing stale analytic distribution totals, the assignment loop in `_compute_discount_allocation_needed` was changed from iterating over `self` to `self.move_id.line_ids`. - While this ensured all lines generated updated distribution ratios, it violated the compute logic: assigning values to records outside the current compute batch (`self`). - By executing `line.discount_allocation_dirty = True` on external sibling lines, the method forced the ORM to trigger out-of-band `write()` calls. These writes re-triggered dependency checks (`_field_will_change`), which invoked the compute method again, leading to a recursive loop. **Fix:** 1. Revert the assignment iteration back to `for line in self:`. 2. To preserve the intention of the previous commit (ensuring all lines recompute their shared distribution pool when one line changes), modify the method's `@api.depends` to be `move_id.line_ids.discount` and `move_id.line_ids.analytic_distribution`. By declaring these relational dependencies, modifying a single line now batches all sibling lines into `self` from the start. This allows the lines to synchronize properly without triggering new ORM writes, eliminating the recursion. opw-6451854 closes odoo#282050 Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Allow resetting sent moves to draft. Ensures a rectificative flow exists or is created. Allow to create an empty rectificative report (if no more invoices to report after being reset to draft). Task: 6273211 Backport of odoo@8010511 This commit also makes minor changes that where done in the 18+ forward ports but not in the 18.0 branch itself (removing 'l10n_fr_pdp_bypass_draft_check' in tests and correcting one comment). closes odoo#282260 Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
|
@royle-vietnam Viindoo Test Suite has failed! |
viinbot
added
🚀 Queue
🚀 Building
⚠️ Failed
and removed
⚠️ Failed
🚀 Queue
🚀 Building
labels
|
@royle-vietnam Viindoo Test Suite has failed! |
Merge 3be5b00 resolved addons/base_import/i18n/vi.po by keeping our translations on top of the new upstream header, but left the trailing ">>>>>>> refs/remotes/odoo/17.0" line behind. polib then fails with "Syntax error in po file (line 1010)": Odoo logs an ERROR while loading translations on every install/update for vi_VN and vi, base_import ends up with no translation at all, and runbot turns the build red on that ERROR.
Collaborator
Author
|
@viinbot dep-add git@github.com:royle-vietnam/tvtmaaddons.git#v17_fix_viin_hr |
|
@royle-vietnam dependency |
Collaborator
Author
|
@viinbot dep-add git@github.com:royle-vietnam/erponline-enterprise.git#v17_fix_viin_sem |
|
@royle-vietnam dependency |
|
@royle-vietnam Viindoo Test Suite has failed! |
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
20 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.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr