Thursday, February 6, 2025
33 changes · saas-17.2
Resolved issues and error corrections
Undoing auto-planned shifts in Planning now clears the previous selection from the search bar and removes leftover highlighting. This prevents users from seeing shifts marked as selected after they have already been moved back to unassigned, reducing confusion during scheduling.
Original PR description
Prior to this commit, undoing auto plan results in having the shifts remaining in the searchBar, and therefore still highlighted. This commit aims to reset the selection and the highlight after undo auto plan. To reproduce the bug: 1. In planning, clcik auto plan and then undo. 2. Auto planned shifts which are now in unassigned are still highlighted and the search bar contains these shifts. task: 3999600
This fixes an incorrect test step in the online shop cart flow that was causing automated checks to time out. The change helps keep quality checks stable so future website sales updates can be validated more reliably.
Original PR description
Correct trigger which was wrong, causing JS test to timeout runbot-task-98520
Miscellaneous changes
ELM 5.0 Swissdec Certification Forward-Port-Of: odoo/enterprise#64454
Original PR description
ELM 5.0 Swissdec Certification Forward-Port-Of: odoo/enterprise#64454
**Steps to reproduce:** 1. Create a new Workspace 2. Upload any amount of documents 3. Delete the workspace 4. Go to the Thrash workspace and try to move the documents that used to be in the deleted workspace **Issue:** When deleting a workspace, this one will get archived, however the documents inside of it will be moved to the Thrash and still be linked to the archived workspace, so we will no longer have access to that folder unless we restore it. Then the problem arises when w
Original PR description
**Steps to reproduce:** 1. Create a new Workspace 2. Upload any amount of documents 3. Delete the workspace 4. Go to the Thrash workspace and try to move the documents that used to be in the deleted…
**Steps to reproduce:** 1. Create a new Workspace 2. Upload any amount of documents 3. Delete the workspace 4. Go to the Thrash workspace and try to move the documents that used to be in the deleted workspace **Issue:** When deleting a workspace, this one will get archived, however the documents inside of it will be moved to the Thrash and still be linked to the archived workspace, so we will no longer have access to that folder unless we restore it. Then the problem arises when we try to do this `foldersById[record.data.folder_id[0]]` since foldersById doesn't seem to include archived folders, it will be undefined so we won't be able to read the `.has_write_access` raising a traceback **Solution:** In this case the proposed solution is to follow the behavior in 18.0 where we can not move the documents that are attached to an archived folder unless this one is restored. We get rid of the traceback by checking if we have a folder before directly tryng to read the `has_write_access` Additionally we added an override for `_createCategoryTree` for getting rid of the folders archived, this affects the case where we directly archived a folder and try to move the documents that were inside of it from the thrash. (folder will sill be present in the model when retrieving it with foldersById) Backport of https://github.com/odoo/enterprise/commit/fac02ad43d523e55546ab21f3cc9a44db18d137b opw-4357753 Forward-Port-Of: odoo/enterprise#75322
In the recent fix at 904c7c8a, we forgot the inherited allowed facets and removed too many tags when changing folders. opw-4347910 Original PR: https://github.com/odoo/enterprise/pull/75001 Forward-Port-Of: odoo/enterprise#78616
Original PR description
In the recent fix at 904c7c8a, we forgot the inherited allowed facets and removed too many tags when changing folders. opw-4347910 Original PR: https://github.com/odoo/enterprise/pull/75001 Forward-Port-Of: odoo/enterprise#78616
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the `commercial_partner_id` of `self`. This works well for form views, where `self` is a singleton. However, since the field `product_id` is present in the list view, which has a domain depending on `suitable_product_ids`, the computation is triggered for all tickets in the list view, making `self` not a sing
Original PR description
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the…
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the `commercial_partner_id` of `self`. This works well for form views, where `self` is a singleton. However, since the field `product_id` is present in the list view, which has a domain depending on `suitable_product_ids`, the computation is triggered for all tickets in the list view, making `self` not a singleton. This causes the set of suitable partners to be larger than necessary, as it becomes the collective set for *all* tickets referenced in `self`, leading to false positives where products associated with a specific partner's sales/delivery history might appear suitable for another ticket with a different partner. To address this, we split `self` by `commercial_partner`, as the set of products that could be suitable depends on the partner's sales/delivery history, not on individual tickets. ## Reference opw-4444078 Forward-Port-Of: odoo/enterprise#78550 Forward-Port-Of: odoo/enterprise#78087
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current behavior before PR: If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-". Desired behavior after PR is merged: If an electronic invoice is sent to DGI with a line without product id but with a lab
Original PR description
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current…
Description of the issue/feature this PR addresses:
This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label.
Current behavior before PR:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-".
Desired behavior after PR is merged:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with the product description.
Steps to reproduce the issue:
- Create an electronic invoice on an uruguayan company.
- Add a line without a product and add a label, a unit price, quantity and tax.
- Confirm the invoice and create CFE.
- Check that the field "NomItem" is field with a "-" instead of the product label like this:
```
<Item>
<NroLinDet>4</NroLinDet>
<IndFact>2</IndFact>
<NomItem>-</NomItem>
<DscItem>PRODUCT X</DscItem>
<Cantidad>1.000</Cantidad>
<UniMed>N/A</UniMed>
<PrecioUnitario>20.000000</PrecioUnitario>
<MontoItem>20.00</MontoItem>
</Item>
```
Forward-Port-Of: odoo/enterprise#78551### Before this commit: Clicking on a budgetary position opened the list view showing all budget lines, regardless of the selected budgetary position. ### After this commit: Now, clicking on a budgetary position will open the list view filtered to show only the budget lines associated with that specific budgetary position. ### Technical: In `doActionButton`, we use the `args` if the action type is object. so, `domain` is irrelevant in this context. **task-4195738** Forward-Port-Of:
Original PR description
### Before this commit: Clicking on a budgetary position opened the list view showing all budget lines, regardless of the selected budgetary position. ### After this commit: Now, clicking on a budgetary position will open the list view filtered to show only the budget lines associated with that specific budgetary position. ### Technical: In `doActionButton`, we use the `args` if the action type is object. so, `domain` is irrelevant in this context. **task-4195738** Forward-Port-Of: odoo/enterprise#73785
The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#78643 Forward-Port-Of: odoo/enterprise#77103
Original PR description
The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#78643 Forward-Port-Of: odoo/enterprise#77103
Mod349 tax report in Spanish localization report the total number of intra-community operations. This counter however, does not take into account paid invoices Steps to reproduce: - With an ES company setup - Create an invoice to an EU partner - Register payment for the invoice - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Total number of intra-community operations is 0 opw-4403287 Forward-Port-Of: odoo/enterprise#77527
Original PR description
Mod349 tax report in Spanish localization report the total number of intra-community operations. This counter however, does not take into account paid invoices Steps to reproduce: - With an ES company setup - Create an invoice to an EU partner - Register payment for the invoice - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Total number of intra-community operations is 0 opw-4403287 Forward-Port-Of: odoo/enterprise#77527 Forward-Port-Of: odoo/enterprise#77238
Related to https://github.com/odoo/odoo/pull/196447 Forward-Port-Of: odoo/enterprise#78542 Forward-Port-Of: odoo/enterprise#78533
Original PR description
Related to https://github.com/odoo/odoo/pull/196447 Forward-Port-Of: odoo/enterprise#78542 Forward-Port-Of: odoo/enterprise#78533
Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115
Original PR description
Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115
In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#78600 Forward-Port-Of: odoo/enterprise#75035
Original PR description
In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#78600 Forward-Port-Of: odoo/enterprise#75035
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root': ``` 2025-02-05 10:29:03,827 4815 ERR
Original PR description
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and…
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box.
However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them
This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root':
```
2025-02-05 10:29:03,827 4815 ERROR ? odoo.addons.hw_drivers.tools.helpers: Failed to delete old IoT handlers
Traceback (most recent call last):
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 435, in delete_iot_handlers
unlink_file(*filenames)
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 534, in unlink_file
path.unlink()
File "/usr/lib/python3.11/pathlib.py", line 1148, in unlink
os.unlink(self)
PermissionError: [Errno 13] Permission denied: '/home/pi/odoo/addons/hw_drivers/iot_handlers/lib/ctep/libeasyctep.so'
```
This PR runs Worldline related script under user "odoo" which fixes the ownership/access issues and allows Odoo service to delete the files.
task-4527243
Forward-Port-Of: odoo/enterprise#78544The following `response` was being returned when checking the CFDI status: ``` (Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None} ``` Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is h
Original PR description
The following `response` was being returned when checking the CFDI status:
```
(Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa
proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No
Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None}
```
Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is handled correctly.
Forward-Port-Of: odoo/enterprise#78552Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Fo
Original PR description
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Forward-Port-Of: odoo/odoo#196486 Forward-Port-Of: odoo/odoo#196433
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456
Original PR description
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456
The payment post-processing cron is run every 10 minutes to ensure smooth operations, but waking up crons incurs a non-negligible performance cost. Since the `payment` module is automatically installed with the `account` module, most databases have the `payment` module installed with its cron, even if they didn't enable any provider. This commit disables the cron until a provider is enabled. task-4467217 Forward-Port-Of: odoo/odoo#195482
Original PR description
The payment post-processing cron is run every 10 minutes to ensure smooth operations, but waking up crons incurs a non-negligible performance cost. Since the `payment` module is automatically installed with the `account` module, most databases have the `payment` module installed with its cron, even if they didn't enable any provider. This commit disables the cron until a provider is enabled. task-4467217 Forward-Port-Of: odoo/odoo#195482
Deleting a knowledge_behavior element previously caused a traceback due to deleteRange() removing its nodes, leading to an error when attempting to destroy the oKnowledgeBehavior. This fix ensures proper handling of element deletion. Task-4210216 Forward-Port-Of: odoo/odoo#196417 Forward-Port-Of: odoo/odoo#195451
Original PR description
Deleting a knowledge_behavior element previously caused a traceback due to deleteRange() removing its nodes, leading to an error when attempting to destroy the oKnowledgeBehavior. This fix ensures proper handling of element deletion. Task-4210216 Forward-Port-Of: odoo/odoo#196417 Forward-Port-Of: odoo/odoo#195451
**Current behavior:** After commit https://github.com/odoo/odoo/commit/7c808beaf36853b4d9171ef0981d1ec9c4b73a44 all writes on `date_start` would silently alter the written date value (totally unintuiative for a user & undesired behavior regardless). **Expected behavior:** Only when handling indirect writes on `date_start` from a linked-via-subcontract purchase order should we modify `date_start` to account for the manufacture delay. opw-4489485 Forward-Port-Of: odoo/odoo#195742
Original PR description
**Current behavior:** After commit https://github.com/odoo/odoo/commit/7c808beaf36853b4d9171ef0981d1ec9c4b73a44 all writes on `date_start` would silently alter the written date value (totally unintuiative for a user & undesired behavior regardless). **Expected behavior:** Only when handling indirect writes on `date_start` from a linked-via-subcontract purchase order should we modify `date_start` to account for the manufacture delay. opw-4489485 Forward-Port-Of: odoo/odoo#195742
Versions -------- - 17.0+ Steps ----- 1. Enable Adyen as payment provider in test mode; 2. do an eCommerce checkout; 3. select Adyen as payment option; 4. use the following card details[^1]: - card number: 4111111111111111 - expiry: 03/30 - cvc: 737 - name on card: CARD_EXPIRED 5. click Pay Now; 6. check order chatter on the backend. Issue ----- > Error: Adyen: Received data with invalid payment state: Refused Refusal shouldn't be an invalid payment state.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Enable Adyen as payment provider in test mode;
2. do an eCommerce checkout;
3. select Adyen as payment option;
4. use the following card details[^1]:
- card number: 4111111111111111
- expiry: 03/30
- cvc: 737
- name on card: CARD_EXPIRED
5. click Pay Now;
6. check order chatter on the backend.
Issue
-----
> Error: Adyen: Received data with invalid payment state: Refused
Refusal shouldn't be an invalid payment state.
Cause
-----
Commit 04f75728fd3e accidentally removed an `elif` branch that was added by commit 4d340a330462e specifically to handle refused payments.
Solution
--------
Re-add the `elif` branch.
opw-4481602
[^1]: https://docs.adyen.com/development-resources/testing/result-codes#values-for-testing-result-reasons
Forward-Port-Of: odoo/odoo#196394Continuation of https://github.com/odoo/odoo/pull/185073 Forward-Port-Of: odoo/odoo#190196
Original PR description
Continuation of https://github.com/odoo/odoo/pull/185073 Forward-Port-Of: odoo/odoo#190196
Before this commit: when printing request to ePOS printer is in process, if user moves to home screen in POS the currentOrder becomes null and throws exception. after this commit: currentOrder is stored before processing the request to avoid the exception. opw-3859174 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-p
Original PR description
Before this commit: when printing request to ePOS printer is in process, if user moves to home screen in POS the currentOrder becomes null and throws exception. after this commit: currentOrder is stored before processing the request to avoid the exception. opw-3859174 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 Forward-Port-Of: odoo/odoo#177364 Forward-Port-Of: odoo/odoo#165333
Splitting the function `click` on the Pricelist Button to make it inheritable, by creating a new function called `getPricelistList` that will allow filtering them whenever needed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173010
Original PR description
Splitting the function `click` on the Pricelist Button to make it inheritable, by creating a new function called `getPricelistList` that will allow filtering them whenever needed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173010
When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are r
Original PR description
When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are reserved from pack P - They don't have any 'Destination Package' [Expected] - From the picking list view, by selecting the 2 pickings D : - 'Unreserve' them both - 'Check Availability' them both - Check the pickings D: - Each are reserved from pack P - Each have 'Destination Package' P [Faulty] opw-4272573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193745
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008
Original PR description
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008
Related to https://github.com/odoo/enterprise/pull/78533 Forward-Port-Of: odoo/odoo#196475 Forward-Port-Of: odoo/odoo#196447
Original PR description
Related to https://github.com/odoo/enterprise/pull/78533 Forward-Port-Of: odoo/odoo#196475 Forward-Port-Of: odoo/odoo#196447
Comparing times may give false error because of the precision and time to run a test. This commit adds a delta into which two datetime are considered the same in order to not make the test failing by mistake. runbot : 112119 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 Forward-Port-Of: odoo/odoo#195457
Original PR description
Comparing times may give false error because of the precision and time to run a test. This commit adds a delta into which two datetime are considered the same in order to not make the test failing by mistake. runbot : 112119 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 Forward-Port-Of: odoo/odoo#195457
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
Original PR description
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
Original PR description
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
Related Enterprise PR : https://github.com/odoo/enterprise/pull/64454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194627
Original PR description
Related Enterprise PR : https://github.com/odoo/enterprise/pull/64454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194627
A recent commit [1] removed the Mail Failure .JPG in favor of an .SVG for transparency. This commit restores the .JPG file alongside the .SVG to prevent potential issues. [1]: odoo/odoo@08f1a78f154d3bf80123b91a1deb0980b95c1ca3 task-4531425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196784
Original PR description
A recent commit [1] removed the Mail Failure .JPG in favor of an .SVG for transparency. This commit restores the .JPG file alongside the .SVG to prevent potential issues. [1]: odoo/odoo@08f1a78f154d3bf80123b91a1deb0980b95c1ca3 task-4531425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196784
In SEPA payment files, when a structured reference is used, it is put in the section `RmtInf/Strd/CdtrRefInf/Ref`. This section has a maximum length of 35 characters. Since we only use structured references that are always less that 35 characters, this should not be a problem. However, the way we validated the structured reference was by performing a `re.match()`, which only matches from the beginning of the string. So if more characters would be after the structured reference, it would still
Original PR description
In SEPA payment files, when a structured reference is used, it is put in the section `RmtInf/Strd/CdtrRefInf/Ref`. This section has a maximum length of 35 characters. Since we only use structured references that are always less that 35 characters, this should not be a problem. However, the way we validated the structured reference was by performing a `re.match()`, which only matches from the beginning of the string. So if more characters would be after the structured reference, it would still match and it would be possible to go beyond 35 characters. In this commit, we fix this by using a full match instead of a match from the beginning. [opw-4357554](https://www.odoo.com/odoo/project.task/4357554) Forward-Port-Of: odoo/odoo#194583