merge from upstream 16 20240423 01 #893
Merged
Conversation
This file contains 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
Context In a previous fix odoo#83276 , the `_notify_get_reply_to_formatted_email` method was introduced to prevent edge-cases where the cypthon `email` library might incorrectly fold the “Reply-To” email header. We identified an other corner case where DKIM signature verification might fail on the recipient’s end depending on the tech stack used to verify the DKIM signature vs the one used to DKIM sign it on the sending end. This might be related to how RFC5322 and RFC6376 interact with each other : In RFC5322 defines folding white spaces as follows : ``` FWS = ([*WSP CRLF] 1*WSP) / obs-FWS with obsolete FWS = 1*WSP *(CRLF 1*WSP) ``` While RFC6376 uses : `FWS = [*WSP CRLF] 1*WSP ` Based on this, it seems that for proper header content folding, the specifications expects at least one WSP (space or tab) before a CRLF. Currently when using the `email` cpython library to handle email objects, we observed that when the header value for the “Reply-To” is longer than 68 characters, it will return a folded string representation adding a linebreak after the colon. Example: `Reply-To:\r\n "Marc R.Long Name Jonhson" <catchall@very.long.subdomain@example.com>\r\n` Notice that the there is no WSP between the colon character an `\r\n`. It seems that in this corner case, certain DKIM verification tech stacks (from tests Microsoft Outlook and Rspamd) will miss-read the “Reply-to” header as empty, while others correct for it (Gmail). This in returns leads to the DKIM signature verification failing. As it is impossible to test every possible combination of DKIM tech stacks in the email ecosystem and that until the `email` cypython library handles this corner case correctly, this fix tries to preformat the “Reply-To” more defensively. We also print a warning log if the `record_email` alone is longer than 68 characters (as it will not be folded), inviting the user to shorten it to prevent DKIM verification issues. Unit test fixing: - shortened alias name to prevent the 68 character limit from being triggered during the test_notification_reply_to_batch performance test (as we are not testing the 68 char here) - changed language in test_mail_message_values_fromto_long_name to reflect the new 68 character limit and mutted logger, as it now print a warning message Considerations for the future This PR only prevents the “Reply-To” from being malformed. In theory, the miss-folding could happen to any email header constructed using the `email` cpython library. In practice, the probability of the “To” and “From” being affected is low, as they usually don’t exceed a total of 78 characters as per RFC. Nevertheless if the future shows that this might be a bigger issue, one should think about: * On Odoo side: add a more robust header value formatting applied to all affected headers before the email gets sent out * On Python’s side: work with the `email` library maintainer to find a longterm solution opw-3826296 closes odoo#160982 X-original-commit: 894f981 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When user tries to empty start date or end date in website using editor, a traceback will appear. Steps to reproduce the error: - Install "website_event" - Go to Website > Events > Open any Event > Register > Edit - Now try to empty start date or end date > Save Error: A traceback appears: "TypeError:'<' not supported between instances of 'bool' and 'datetime.datetime'" https://github.com/odoo/odoo/blob/4759c6d1ee09c32381dc56c59c95949fd0e2807c/addons/event/models/event_event.py#L507 Here, When user tries to empty start date or end date, start date or end date will become "False", So it will lead to the above traceback. solution: A try-catch is used to catch typeerror at write of qweb fields. sentry-5038057541 closes odoo#160744 X-original-commit: 087b1a4 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Issue:
When we have open tickets from anyone with
the email domain @proton.me, they are linked
together even though this domain is generic,
not a private one.
same issue with @cegetel.net and @dbmail.com
Steps To Reproduce:
- Create three tickets with "@proton.me"
domain but different addresses.
- See that in the smart button, the tickets
are linked to each other even though the
customers are different.
Solution:
- in `_compute_partner_ticket_count` we check
if the email domain of the partner is in
`iap_tools._MAIL_DOMAIN_BLACKLIST `, if not,
we consider the email to be a company email
which tickets can be grouped by.
- the _MAIL_DOMAIN_BLACKLIST is a list of generic
email providers on which IAP services should not run.
Retrieving company information from them makes no sense.
- To fix this issue I added `proton.me`,
`cegetel.net` and `dbmail.com`
to _MAIL_DOMAIN_BLACKLIST
opw-3786308
closes odoo#160746
X-original-commit: 0258fcc
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
Before this commit, when the user created a new quotation from
Contact->Opportunity-> ("New Quotation" or "Quotations/orders widget
button", archived records could be added to the quotation
(e.g. ,product, taxes...) because the context was set to
active_test = false. After this commit, the context is configured back
to active_test = true when creating a quotation from opportunity.
opw-3802796
closes odoo#160792
X-original-commit: 89b0e33
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Fix various "Using variable xxx before assignment". It was not detected by pylint <= 2.5.0 which was the version enforced on runbot. closes odoo#160886 closes odoo#160967 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Outlook and similar Windows based systems use windows-874 for encoding Thai characters which is not natively known by Python. Simply aliasing the Windows encoding as cp874 adds support for this encoding. opw-3684161 closes odoo#160575 X-original-commit: b991b28 Signed-off-by: Julien Castiaux (juc) <juc@odoo.com> Co-authored-by: Julien Castiaux <juc@odoo.com>
Issue: ====== The powerbox keep increasing in size when you input. Steps to reproduce the issue: ============================= - Install arabic - Go to notes - write `/`, you can see the powerbox is a bit smal - use `down/up`arrows to navigate in the powerbox. - The powerbox width increase until finally gets to it's intended position. Origin of the issue: ==================== Since we are providing that `marginRigh` should be equals to `20` in `getRangePosition` we will move the powerbox to the left a bit and then with the style property `max-width=100%` it will increase in size because the current size is a bit small for it. So at every key pressed it will increase by 20px until it gets to a point where everything is set and the `marginRight=20` is finally visible. Soltuion: ========= We set min-width as max-content so we can position correctly the powerbox knowing it's final width. task-3721794 closes odoo#157668 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce: - Add the same tag to 13 different blog posts. - On the "Blog" page, click on this tag to filter the blogs. -> Problem: the result displays "12 Articles" but they are actually 13. In this case, the result displays "12 Articles" as they are 12 articles on the current page. When going on the second page of the results, "1 Article" is displayed. This problem is solved by displaying the total number of articles found after the filtering operation rather than the number of articles on the page. opw-3802729 closes odoo#160997 X-original-commit: 0e8490b Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com> Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Before this commit, when adding a new grid item in a grid by using the "Add Elements" option, if the page was scrolled such that the top of the grid was not visible, this new grid item may not always be visible. This is annoying as the user could add an element and not see where it appeared and would therefore need to look for it. This commit fixes this by making the page scroll to the added grid item if more than half of it is not visible. A test is also added. Steps to reproduce: - Drop the "Text-Image" snippet and enough snippets under it to have a scrollbar. - Toggle the "Text-Image" snippet to grid mode. - Scroll the page so the top of the grid is not visible. - Add a new "Button" with the "Add Elements" option. => The button is not visible. task-3616138 closes odoo#158838 Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Only delivery carriers that can communicate with the outside should be deactivated. Every time a database is neutralized, all delivery carriers are deactivated. In staging or test databases this should not be the case, only delivery carriers with an external connection, i.e. delivery carriers with an external provider should be deactivated. Delivery carriers with fixed price or based on rules should not be deactivated with every neutralization. This way Odoo can continue to operate with shipping methods without prejudice to the users in neutralized databases. @moduon MT-5612 closes odoo#160443 Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
The logger show "Job done" before the flush. But if during the flush an error appear (sql constraint, validation error during computed field, ...), the log contain "Job done", but is not True. The time to compute the cron is not good because it doesn't contain the flush time. closes odoo#161079 X-original-commit: 3f7b19b Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
task-3718751 Part-of: odoo#152897
Currently when we have an Analytic Filter applied on an accounting report, we lose that filter when we click on any amount to audit the journal items. This fix makes sure that when auditing, we only view the journal items filtered by the Analytic Filter. In order to do that, we extend the search function in the analytic mixin to allow searching on analytic account ids. task-3718751 closes odoo#152897 Related: odoo/enterprise#55972 Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
This commit fixes the 'og:site_name' metadata, which previously defaulted to the company name (see [1]), causing issues for multi-site setups. Now, the metadata actually uses the site name. Steps to reproduce: - Navigate to any page - Right-click and select "View Page Source" - In the <head> section, observe the meta property "og:site_name" set to "MyCompany". [1]: odoo@156955d opw-3791082 closes odoo#161053 X-original-commit: 24ea3ca Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Bug:
1. Have at least 2 companies ("A" and "B")
2. Export an xml (Bis 3 for instance) for an invoice with customer
"Azure Interior"
3. Set a company on "Azure Interior" (say: A)
4. Import the xml in multicompany mode, with current company = B The
partner "Azure Interior" should be retrieved, but when writing it on the
invoice, it will throw a UserError "odoo.exceptions.UserError:
Incompatible companies on records: 'Draft Invoice (* 63)
(INV/2024/00006)' belongs to company 'B' and 'Partner'
(partner_id: 'Azure Interior') belongs to another company."
Cause:
We try to write a partner on an invoice belonging to another company. It
only occors when we have several companies selected because there is the
global rule `base.res_partner_rule` that will add `('company_id', 'in',
company_ids + [False])` to any search domain on the partner
(`company_ids` is replaced by `env.companies.ids`, see `_eval_context`).
Fix:
Ensure any search domain contains `env.company.id`: the `company_id` of
the move being created.
opw-3829223
closes odoo#161130
X-original-commit: fce296a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Fine-tunning of odoo#161079 closes odoo#161237 Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Steps to reproduce:
- Install pos_loyalty module
- Go to Point of Sale app > Products > Discount & Loyalty
- Create a New program with:
- Program Type: Next Order Coupons
- Validity: Today's date for example
- Conditional rule with a Minimum Purchase of 0.00
- Start a new POS session. Add a product and click Payment.
- Validate the order.
- In the receipt shown, notice how the text show 'Valid until: no expiration' although a Validity date is defined!
Investigation:
- In `confirm_coupon_programs`, `coupon_create_vals` lacks `expiration_date` https://github.com/odoo/odoo/blob/03856863a644fbc588edb6e63168a6c4e15d5d92/addons/pos_loyalty/models/pos_order.py#L72-L78
- To add the `expiration_date`, `date_to` has to be in `coupon_data` but it's not included.
- `coupon_data` comes from `https://github.com/odoo/odoo/blob/03856863a644fbc588edb6e63168a6c4e15d5d92/addons/pos_loyalty/static/src/js/PaymentScreen.js#L78`
opw-3838427
closes odoo#160633
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Before this commit, users could not disable the Terms and Conditions display on the product page from the Customize tab of the web editor. To remove it from the product page, the only workaround was to remove the text in that div. Now, a button will be available in the Customize tab of the web editor to quickly show or hide the Terms and Conditions. closes odoo#161230 Signed-off-by: Valentin Chevalier <vcr@odoo.com>
closes odoo#159879 Task: 3839559 Related: odoo/enterprise#59772 Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
The `stock.move:_action_done()` already reserve the next mto moves at validation. Calling the reservation method after the validation again may lead to unwanted results like calling `check_entire_pack()` and messed up the result_package_id on the stock move lines. Task : 3764822 closes odoo#160898 X-original-commit: 364ffcf Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com> Signed-off-by: William Henrotin (whe) <whe@odoo.com>
steps to reproduce: - Go to Accounting > Accounting > Actions > Lock Dates - Set a Tax Return Lock Date to a date of the previous month - Create and confirm vendor Bill with a taxed line of positive price - Go to Accounting > Reporting > Audit Reports > Journal Report - Hover over the Vendor Bills and click on "journal items" - Add the optional vehicle field to the recods - Select your expense line and try to add a vehicle > Invalid Operation "You cannot modify the taxes related to a posted journal item..." Cause of the issue: Modifying the "vehicle_id" of the account move line will trigger a call of the `_sync_dynamic_line` method in order to modify other account move line linked to the same account move: https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move.py#L2285-L2287 During the call of this write method, the account move line that we did not directly modified will not be excluded: https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move_line.py#L1571 as `..._field_will_change(line, vals,"vehicule_id")` will be `True`. The error will therefore be raised two lines later because a 'tax_id' is present in vals as a 'tax_id' was set on our related account move line. Expected behaviour: Since the 'tax_id' present in vals is the same as the one already set on our account move line, we are not modifying the taxes related to a posted journal item and we should not raise the error. opw-3810718 closes odoo#159919 Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Issue ----- The trailing text on the `ir.sequence` view is unreadable due to spanning only one column which leads to awkward line-wrapping. Steps ----- - Go to Settings -> Technical -> Sequences. - Select the sequence with code "sale.order". - Have a look at the legend. Cause ----- The <div> containing the text spans only one column which is not suitable for long text. opw-3820141 closes odoo#160912 Signed-off-by: Moataz Hussein (mohu) <mohu@odoo.com>
On pages without visible dropzones (including if one exists in a currently invisible snippet), snippets should not be droppable from the editor. Up to now, the behavior did not take into account invisible snippets, leading to confusing situatons (cf. steps to reproduce). This commit makes sure that the drag & drop is disabled if the only spot available is within an invisible snippet. It reenables the D&D if an invisible snippet is shown. Steps to reproduce: - Go to `/web/login` and edit the page - Most snippets can't be dragged & dropped => Good. There is no dropzone for them. - Activate the cookies bar in the settings - Go to `/web/login` and edit the page => The "structure" snippets can now be dragged & dropped, even though the only place where it is possible is the cookies bar, which is invisible. It looks like a bug for the users who try to drop blocks on the main page and cannot. opw-3829660 closes odoo#161148 X-original-commit: 922b4ba Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com> Signed-off-by: Robin Lejeune (role) <role@odoo.com>
### Contains the following commits: odoo/o-spreadsheet@6c7d51009 [REL] 16.0.38 odoo/o-spreadsheet@51860d7d6 [FIX] sheetview: pageUp/Down with frozen rows Task: 3847414 odoo/o-spreadsheet@bb5d10e8e [FIX] misc: faster `deepEquals` odoo/o-spreadsheet@a9ff24f74 [FIX] xlsx: Shortcut `deepEquals` for primitive types in `pushElement` Task: 3733743 odoo/o-spreadsheet@76151cdf1 [FIX]xlsx: replace json.stringify with deepEquals Task: 3733743 odoo/o-spreadsheet@de8a78ff6 [FIX] xlsx: remove useless normalization Task: 3733743 odoo/o-spreadsheet@fb640e4d6 [FIX] XLSX: simplify `pushElement` helper Task: 3733743 odoo/o-spreadsheet@9fcb43d2f [FIX] Composer: pressing enter in the link editor closes odoo#161314 Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Steuernummer was being validated at tax report xml generation. The check was moved to the company form view. Moreover, the field was set visible in the company form view for multivat. It should be a constraint raising when trying to set the steuernummer to the company; there is no point in only checking it at XML generation. task-3809218 closes odoo#161309 X-original-commit: 5ba4247 Related: odoo/enterprise#60435 Signed-off-by: Olivier Colson (oco) <oco@odoo.com> Signed-off-by: Hesham Saleh (hsal) <hsal@odoo.com>
`_UNSAFE_ATTRIBUTES` was changed from a `list` to a `set` in odoo#151989. odoo/odoo@cde2781 Reset it to a `list` as before, by retro-compatibility concerns, in case developers used features not working on `set`. For instance: - `_UNSAFE_ATTRIBUTES.append` - `_UNSAFE_ATTRIBUTES.extend` - `_UNSAFE_ATTRIBUTES + ['foo']` The opportunity is taken to add `_co_code_adaptive`, which is a new attribute added from Python 3.11, hence available from Ubuntu Noble. Firstly added as `_co_quickened` in python/cpython@001eb52 Then renamed to `_co_code_adaptive` in python/cpython@2bde682 The opportunity is also taken to move `mro` out of the `Python 2 functions` section, as `mro` is available in Python 3, hence making the comment confusing. Part-of: odoo#151989
The test test_tz_legacy will fail if the taget does not exist on the operating system. This is breaking in some versions of the tz-data package. Don't make this test fail if the target is missing. closes odoo#161259 X-original-commit: 276eb01 Signed-off-by: Christophe Monniez (moc) <moc@odoo.com> Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
…ndor bill Steps to Reproduce : - install indian Accounting module - click on invoice - go to vendor bills - create new Issue: - while creating new and confirming, it will throw a warning message, as this warning required only for eInvoice only (while confirming the invoice) not for vendor Bills. Cause: - while generating warning message there is no specific condition like that it is not for vendors Solution: - if we gave condition that this warning message is only for out_invoice then the issue will be solved. task-3657558 closes odoo#160560 X-original-commit: 5dba626 Signed-off-by: Laurent Smet (las) <las@odoo.com> Signed-off-by: Supriya thirumuru (suth) <suth@odoo.com>
The goal is to modify the acconuts that take please in those entries. A typical example is a company that wants to recognize cost of goods sold for the input and output at the same time, instead of waiting for the customer invoice. closes odoo#160295 X-original-commit: 4de2520 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
[This first commit] made it possible to have an error when there was no comparator for a field with conditional visibility. [This second commit] prevented an error from occurring in this case. The purpose of this commit is to prevent the user from getting a conditional visibility configuration for a form field where there is no comparator. Steps to reproduce the problem: - Go to /contactus. - Edit page. - Click on the "Your Company" field. - Select "Visible Only If" for the "Visibility" option. - Click on "Visible Only If" again. => The comparator is not defined. Another way to have the issue was: - Drop a form on a page. - Click on the "Your Company" field. - Select "Visible Only If" for the "Visibility" option. - Set visible only if Your Name is equal to "test" as condition. - Click on Your Name field. - Change the field type to Radio Buttons. => The comparator is not defined. This commit fixes those two cases. Technical information: When we change the field's visibility to conditional (`setVisibility`), we add a default visibility dependency (`_setVisibilityDependency`). At this point, the comparator is removed and added in `_renderCustomXML`. `_renderCustomXML` was only called if the visibility dependency had changed. [This first commit]: odoo@910897f [This second commit]: odoo@808780c opw-3806409 closes odoo#161463 X-original-commit: 770cc16 Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com> Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
|
@duong77476-viindoo Viindoo Test Suite has failed! |
viinbot
added
🚀 Queue
🚀 Building
⚠️ Failed
and removed
⚠️ Failed
🚀 Queue
🚀 Building
labels
|
@duong77476-viindoo Viindoo Test Suite has failed! |
|
@viinbot rebuild |
|
@duong77476-viindoo PR in the queue to wait for rebuild! |
duong77476-viindoo
changed the title
duong77476-viindoo
changed the title
viinbot
added
🚀 Queue
🚀 Building
🚀 Running
|
@duong77476-viindoo Viindoo Test Suite has passed! |
viinbot
added
🚩 Done
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
https://drive.google.com/file/d/1TAghXO3ZdALrZrWVlLCG4x2cdKTeH2RR/view?usp=drive_link
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr