Steps to reproduce:
- Create a project with a task with a sub-task
- Assign manually the sub-task to the project
- Create a product that creates a project based on this product template
- Create an SO with that product
> A copy of your project template will be created and assigned to the SO
Expected Behavior:
Just as in 16.4, the copy of the subtask created during this process
should be associated with the copy of your project template.
Current Behavior:
The subtask is associated with the original project template.
Cause of the issue/Fix:
Confirming the SO will call the copy method on your project template.
During this call copies of its task and sub-task will be created and
should then be remapped to the correct project/task using by the
`map_tasks` method call:
https://github.com/odoo/odoo/blob/f31174e02157e612650e77ebba3ed1fe54b96776/addons/project/models/project_project.py#L436-L437
This use to do the job correctly in 16.4 because of these lines:
https://github.com/odoo/odoo/blob/ce28edbaae5a9af0a8c6e1f2addf4285ec56e9e1/addons/project/models/project_project.py#L415-L419
However, these were removed by Commit 62e53fa, probably because the new
write method of the "project.project" model introduced by this commit
sometimes relies on the "project_id" of these tasks and this information
should be consistent with the future value of the "project_id" of these
tasks. However, the "project_id" of these tasks should still be remapped
to the copied project at some point and in my opinion this should be
done before the new write method is called, so that this method can be
used correctly.
opw-3823013
closesodoo/odoo#160625
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Rewrite the mapping from xmlid to tax to only take into account
standard taxes from the 'account' module
closesodoo/odoo#161945
X-original-commit: d31f3382453a1d288b732e7cb2aa27b26dcfe645
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit:
* when a user changes 'user_id' to set the same previous 'user_id', the
assign date 'date_open' is updated but it should not as the responsible
did not change;
* when a user changes the salesperson 'user_id' of a crm lead, it triggers
a recompute of 'team_id' that triggers a recompute of 'stage_id' that
updates 'date_last_stage_update' even if the stage does not change, which
happens frequently when changing leads within a given team (new assign,
salesperson on holidays, ...)
* when merging opportunities, 'user_id' can be set on the main opportunity
which triggers a recomputation of both 'date_last_stage_update' and
'date_open' as explained in above points;
Reason:
The 'date_last_stage_update' field depends on 'stage_id' which depends on
'team_id' which depends on 'user_id'. As a result, when 'user_id' changes,
'date_last_stage_update' also updates.
Moreover those fields are implemented using editable stored computed fields
which are triggered everytime a value is given to those fields, even when
the same value is given.
After this commit:
'date_last_stage_update' and 'date_open' will only update when there are
real changes.
Also fix 'date_open' update when lead is converted into an opportunity.
'date_open' is the date when a user is assigned to a lead / opportunity. It
should not be set when converting a lead to an opportunity, as those two
flows are different. Only setting a responsible should update it.
Task-3515225
closesodoo/odoo#161918
Forward-port-of: odoo/odoo#144848
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
date_open should not be set when there is no user_id set. Let us be coherent
so that we can see the effect of assigning users that updates the date_open
field.
Task-3515225
X-original-commit: 3720e5aefd7bf9971d0d7b6fc93fc90c1eeecad3
Part-of: odoo/odoo#161918
'date_open' is the date when a user is assigned to a lead / opportunity. It
should not be set when converting a lead to an opportunity, as those two
flows are different. Only setting a responsible should update it.
Task-3515225
X-original-commit: a3dbe23b83e7aae108ff72737c69c783e059f603
Part-of: odoo/odoo#161918
Before this commit:
* when a user changes 'user_id' to set the same previous 'user_id', the
assign date 'date_open' is updated but it should not as the responsible
did not change;
* when a user changes the salesperson 'user_id' of a crm lead, it triggers
a recompute of 'team_id' that triggers a recompute of 'stage_id' that
updates 'date_last_stage_update' even if the stage does not change, which
happens frequently when changing leads within a given team (new assign,
salesperson on holidays, ...)
* when merging opportunities, 'user_id' can be set on the main opportunity
which triggers a recomputation of both 'date_last_stage_update' and
'date_open' as explained in above points;
Reason:
The 'date_last_stage_update' field depends on 'stage_id' which depends on
'team_id' which depends on 'user_id'. As a result, when 'user_id' changes,
'date_last_stage_update' also updates.
Moreover those fields are implemented using editable stored computed fields
which are triggered everytime a value is given to those fields, even when
the same value is given.
After this commit:
'date_last_stage_update' and 'date_open' will only update when there are
real changes.
Task-3515225
X-original-commit: 8dc18806847e5240dba6f05bdd80d313bf466ebf
Part-of: odoo/odoo#161918
Just to see how it behaves currently, as we are going to fix some unwanted
changes. Notably
* setting user_id to the same value as before should not update the
date_open value;
* setting stage_id to the same value as before should not update the
last stage update value;
* triggers generate chain update of those fields (changing team_id
changes user_id that changes date_open, ...);
Task-3515225
X-original-commit: a1c72fff151524f636fae3f253d33b8228d0add9
Part-of: odoo/odoo#161918
While in practice you would never get this inverse
called with more than one record at a time, it is
still wrong to get the company of self in the loop.
Fixing it to keep good conscience :)
closesodoo/odoo#161979
X-original-commit: 56fe4f71f0cca2ca11624bd267e1dec4de2ac929
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
`base_vat.view_partner_base_vat_form` creates a new div `vat_vies_container` referenced by other views such as `l10n_mx_edi_stock.mx_partner_operator_form`
All these extension views have the same priority and in this case the later is trying to access the div before it is even created.
We fix this issue by changing the priority of the view that creates the div from 16 to 15.
closesodoo/odoo#161902
X-original-commit: 67e7289296ea12e69cb07864a2974cd5d4e46cf2
Signed-off-by: William André (wan) <wan@odoo.com>
This commit adds a new module to allow delaying the sending of sales
order confirmation emails, thus removing a performance bottleneck in the
order confirmation flow.
This is particularly useful for "flash" sales in which a large number of
event tickets are sold in a very short time span. When the emails are
scheduled to be sent right away, the email rendering that is part of the
payment post-processing keeps the worker busy. When the system parameter
`sale.async_emails` is set to `True`, the email rendering is delegated
to a cron, allowing the payment post-processing to execute much faster.
task-3782827
closesodoo/odoo#157612
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds the database ID to the IAP calls made to generate text.
It permits to prevent abuses of OpenAI calls.
task-3740440
closesodoo/odoo#154615
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
How to reproduce
- Send an email to catchall@exemple.com, random@exemple.com
(Note : random@exemple.com is an email witch does not exist)
--> Issue the email is not bounced
To justify the change, this was actually the behavior a while ago, prior to odoo-dev@68a457e
The intent of that commit was to consider other possible routes, so this commit
doesn't contradict the change.
Task-3714565
closesodoo/odoo#161782
X-original-commit: df0c05afbf81ce41c9b1b4cfe93476d4ca397749
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps:
- Login as "Mitchel Admin"
- Install hr_skills_survey
- Delete all employee except "Mitchel Admin"
- Open "My profile"
- Open "Resume"
- Add a skill
Actual result:
- Error due to missing employee
- default_employee_id is using the current record id so a user id
- default_employee_id is not the correct ID
- Can lead to record not existing error or access error
Expected result:
- No error
- default_employee_id is the correct employee of the user
- Default employee in dialog is "Mitchel Admin"
opw-3852542
closesodoo/odoo#161636
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
- Create a vendor bill with landed costs
- Add section and note lines
- Try posting the bill (ERROR)
Bug:
display lines should be skipped
opw-3715660
closesodoo/odoo#161791
X-original-commit: 3174c4a793f24782d835a15d96376e45b5f333e4
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
Create and print an SO for a customer based in Luxembourg
Expected behavior:
According to Bpost and to the Post of Luxembourg, the zip code should be
displayed before the city name in the address format in Luxembourg.
Current behavior:
The zip code is displayed after the city name.
opw-3791142
closesodoo/odoo#161738
X-original-commit: 83b38fab6cc69d0ed2c6abae34f2b4e76ef8a601
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
In IT localization open tax "0% S (Services)"
Issue: invoice repartition line tax tag is "+02", it should be "+03"
opw-3860109
closesodoo/odoo#161696
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
There is 2 issues with it:
- People that want to use multiple picking type or multiple store after
manufacturing locations. It's not possible since the equals is strict
on the warehouse store after manufacturing picking type.
- The procurement group always use the default manufacture picking type
and ignore the picking type on the manufacture rule that will be use.
This commit checks if the location is a child of the post production in
order to create the procurement group. It would be an issue for people
having multiple step in post prod. But it could be fix by using a subset
of the warehouse post production location.
Check if we have a manufacture rule with the same warehouse in the
current route. It's not perfect but it could give a more accurate result than
today.
closesodoo/odoo#161690
X-original-commit: f82a0f2ea8f3c57bae915520f9e4a25b54b81ce4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue
-----
Reconciliation models are not searchable by specific fields (e.g. name).
Steps
-----
- Open Accounting -> Configuration -> Reconciliation Models.
- Try typing something into search.
- No field are suggested to search on.
Cause
-----
No search fields are defined for `account.reconcile.model`, only filters.
opw-3847744
closesodoo/odoo#161648
X-original-commit: 973ad96c7cf4b37fbdeea463bbf676cfee920975
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Steps to reproduce:
- Change the recruitment access rights of Marc Demo to "Interviewer".
- Go to Recruitment > Applications > All Applications.
- Create a new application and add Marc Demo as follower of the chatter.
- Write and send a message on the chatter.
> Marc Demo will not be notified
Expected behavior:
As discussed the PO of the recruitment module (gmf), since users with
"interviewer" access rights have access to the chatter and since the
sensible informations are now shared via the salary offer model instead
of relying on the chatter of the application model, the followers of the
chatter with "interviewer" access rights should be notified if pinged on
a log note or if a general message is sent.
Cause of the issue:
Since sensitive informations used to pass through the chatter, users
with "interviewer" access rights did not have access to it, and were
removed on purpose from the recipients of the notifications:
https://github.com/odoo/odoo/blob/cd6ed7f9fd2e0654cfb0672d7a9536dca21035cf/addons/hr_recruitment/models/hr_applicant.py#L376-L379
to avoid any leak of sensible information.
Note:
This access right did not exist before saas-16.4
opw-3783965
closesodoo/odoo#161198
X-original-commit: 6e8795cf5a7d51c4682941a253fb158e8e7e874e
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
An update made to the tremol device has changed the expected content of
the price field. It now expects up to 15 characters in this position,
with a maximum of 5 decimal places.
At present we can send prices with a decimal position greater than 5,
doing so will result in an error from the fiscal device.
This commit adapts the content that gets serialised in order to ensure
that the decimal provided is no longer than 5 decimal places.
closesodoo/odoo#161804
Task-id: none
X-original-commit: 3373ac3a7945d25fee70d114816ce23a16d6e0ef
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
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
closesodoo/odoo#161333
X-original-commit: 6480dccfea696e759d0ed4225f4edc033adbfc0e
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
This commit will make a `willDrag` information available to the
draggable_hook_builder context.
This is needed to fix a resize issue in the gantt view.
See correlated enterprise pull request.
closesodoo/odoo#161670
X-original-commit: 53254591c4a6a31483f409aa2fa072ac2ed0b3db
Related: odoo/enterprise#60623
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
- Transfer move line with amount_currency $0, balance 1000đ
- Wizard transfer not generate counterpart lines
closesodoo/odoo#161727
X-original-commit: e5b84edd7a5aefc3f08db23e6ede8a380c2cb6f9
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
The patch function was changed at commit [1]. This introduced a call to
`Object.hasOwn` which is the preferred way to check if an Object has a
property as its own. However, after multiple user reports, it seems like
a significant amount of user and website visitors still use browsers
that do not have Object.hasOwn implemented.
This commit adds a polyfill to add Obejct.hasOwn in case it is not
found.
[1]: https://github.com/odoo/odoo/commit/04fddc19d4aedd8105e0fda5582288c2bb1833fe
Fixes https://github.com/odoo/odoo/issues/142022
opw-3824593
Part-of: odoo/odoo#160758
It's not possible to push in intercompany location because the warehouse
is set base on the initial move. However in intercompany we don't
have a warehouse in the most cases.
Also there is an issue with the cache holding the route on the product
for the current company. So we invalidate it to retrieve all the routes
among the different companies
closesodoo/odoo#161717
X-original-commit: f16e0a2c954f1dce14880d62b6c07518f7317d1b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Usecase to reproduce:
- Company A Stock -> Interco -> Push to Company B stock
- Create a SO from company A with company B as customer
- Create a pull from WH/A to interco
- Create a push interco to WH/B
- Confirm the SO
Current behavior:
Wrong company on stock.move from interco to WH/B due to rule with
company A
Expected behavior:
Pushed to stock B
It happens because the rule_id is not set during the copy of push_apply.
So it just keep the same rule than the move triggering the push (WH/A ->
interco).
X-original-commit: dc58d7913131f1f4dbeb0e3337e61e0b21f6f0d9
Part-of: odoo/odoo#161717
The linked PR: https://github.com/odoo/odoo/pull/155157/files
Added a default props 'productType' for ProductCatalogOrderLines, the value of this prop wasn't loaded by the backend correctly
resulting in a traceback when in debug mode and trying to open the catalog from sale/fsm
and another traceback when trying to open the catalog from the purchase form
This PR loads the type of the product into the dictionnary corretly
closesodoo/odoo#161541
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
- Create a Customer Invoice CI
- Register a full payment P
- Create a Bank Transaction BT
- Reconcile BT with P
- Go to the payment's move and click on "Reverse Entry" button
-> First issue: Two buttons ("Reverse" and "Reverse and create invoice")
It should be only one ("Reverse")
- Click on "Reverse" button
-> The invoice is still marked as "paid", it should be "not paid"
The reason is that `is_cancel_needed` variable is not well computed
in `reverse_moves()` as since 4d3ac4cbd8,
there is no `refund_method` on the reversal wizard, which was used
instead of `is_modify` parameter, which is not enough in our case.
opw-3772117
closesodoo/odoo#161534
X-original-commit: 5f3c1957b391e3395dbebac4ccb6592af9e4a7dd
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Steps to reproduce:
- Drop an Text - Image block
- Click on the Image
- Click on the link button next to replace
- Try typing a URL
=> Typing a URL is hard because the widget keeps re-rendering
Reason: Since [1], the jQueryUI urlcomplete widget was changed into an
OWL widget. This added a call to `urlChosen` on input, which leads to
the SnippetsMenu re-rendering the options.
This commit fixes that by remove the call to `urlChosen`. Nothing is
lost since the input is already handling its own changes. Instead,
urlChosen is only called when selecting an element from the dropdown.
[1]: https://github.com/odoo/odoo/commit/86a9171ec7790aa09f2b9a50dcb26deb029e8bedclosesodoo/odoo#161045
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Co-authored-by: =?UTF-8?q?Nguy=E1=BB=85n=20=C4=90=E1=BA=A1i=20D=C6=B0=C6=A1ng?= <daiduongnguyen2709@gmail.com>
In `SET_FILTER_MATCHING_CONDITION` we would call `SEE_RECORDS_PIVOT_VISIBLE`
twice but since the function returns a boolean value, the second call
was useless as we already knew the outcome. This revision alleviates a
bit the cost of computing the cells' clickable actions.
On A sheet with 480 visible cells, each of them matching the full
condition, the time spent in `getClickableCells` goes from 19ms to 14
ms on Google Chrome and from 42ms to 29 ms on Firefox.
closesodoo/odoo#161656
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Issue: When a course is set to 'On Payment' and
linked to our 'Course Access' product, users
encounter an issue where they cannot view the
final screen of the payment process when selecting
payment methods like 'wire transfer'. This occurs
because the payment status remains 'pending', and
the user has not yet been granted access to the
course, meaning no invitation link is available.
Steps to Reproduce:
1. Install website_sale_slides.
2. Create or modify a course with the 'On Payment'
status.
3. Link it to a 'Course Access' product.
4. Navigate to the website and attempt to purchase
the course.
5. Proceed through all the steps of the payment
process.
Solution: The template needs to accommodate
scenarios where certain payment methods do not
immediately provide an invitation link.
Even without the invitation link, it should still
display the last payment screen, awaiting payment
confirmation to grant access.
opw-3683024
closesodoo/odoo#161618
X-original-commit: eee6222763b4d88f75994b498d15cd4358899fc1
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
Create company A with company currency USD, company B with company
currency VND.
Set company B-VND in payment terms
closesodoo/odoo#161044
Expect: currency payment terms is VND
Signed-off-by: William André (wan) <wan@odoo.com>
Issue: In Link Tracker for our website, when generating the link, if we
try to copy the generated url with the copy value, instead of copying
the url we are getting undefined.
Steps to reproduce:
1. Install website_links.
2. Go to the website and go to Site > Link tracker.
3. Generate a new link and try to copy.
Solution: Due to the recent changes that came from the changes made in
9638423 where we replace the ClipboardJS with Web API and hombrew
polyfill, there are still some button that is not adapted yet, and in
this case what happens is that we have a difference dataset format for
the clipboard content, being 'clipboardText' instead of 'clipboard-text'
opw-3806495
closesodoo/odoo#159674
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When updating the categories, if by any chance there is a loop in the
category hierarchy, the current code was falling into an infinite loop.
With this commit, the graph loop is broken by clearing a parent_id, and
if the resulting module category path is wrong, a clean new one will be
recreated anyway.
This allows unblocking uncomfortable situations where people cannot
update the modules list any more. In 15.0, [a check][1] has been
introduced to prevent the existence of recursive categories, but as it
is a python check it doesn't prevent corrupted data to remain corrupted.
OPW-3704007
Related to odoo/upgrade#5574
[1]: odoo/odoo@6932714200closesodoo/odoo#161583
X-original-commit: f2765d2cab5671a010404c36842bf1b4c4d6350b
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Since [1] positioning of popovers targeting an element contained in an
iframe is permitted.
This commit will ensure the popper's element positioning is correct in
the following case: have a popper
- outside an iframe
- targeting an element that is inside it
- and no container element has been given (default is used)
**Before this commit**
The default container that is used is the target's owner document
element, a.k.a. the iframe's html element.
**After this commit**
The default container that is used is now the popper's owner document.
** Side notes **
This bug has been found when working for the following taskid-3603843
It is required for this task and will get fw-ported through the master
branch.
[1]: d6afa9f325closesodoo/odoo#161568
X-original-commit: e664b2367f482aa6edc492db16ec92ffff1ac0a1
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@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.
closesodoo/odoo#161505
X-original-commit: f477433a9092deb21236b90114759316b13bc1bc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
After `_check_combo_inclusion` was added, it broke product creation for
users without sales rights (e.g. stock managers). This commit fixes
the issue by using `sudo().search`.
closesodoo/odoo#161313
Signed-off-by: Joseph Caburnay (jcb) <jcb@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]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
[This second commit]: https://github.com/odoo/odoo/commit/808780c89cfba940957f7410f787de31e31bda27
opw-3806409
closesodoo/odoo#161527
X-original-commit: 770cc162d6de82818d8e29bf156bb01f65ca8e2c
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Prior to this commit, splitting an order would create a new order,
causing it to appear again on the preparation display. This could
lead to the kitchen preparing the same order twice. The sequence of
events was as follows:
1. The order is placed.
2. The kitchen receives and prepares the order.
3. The waiter delivers the order to the table.
4. The client receives the bill and requests a split.
At the point of splitting, a new order is created. This duplicate order
should not be sent to the kitchen as it represents a meal that has
already been prepared and consumed. This commit resolves this issue by
preventing display of duplicate orders to the kitchen during order
splitting.
Enterprise PR: https://github.com/odoo/enterprise/pull/60537
opw-3809693
closesodoo/odoo#161498
Related: odoo/enterprise#60537
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Issue:
======
traceback when clicking on gradient colorpicker in mass_mailing
Steps to reproduce the issue:
=============================
- Got to email marketing
- Add some text
- Select the text and go to graadient and activate custom
- click any color in the colorpalette -> traceback
Origin of the issue:
====================
Some colorpickers are created inside the snippets sidebar and then gets
removed by `_updateRightPanelContent` in `SnippetsMenu` so the owl
components corrosponding to them will have `this.el = null` which will
cause a problem when updating the props since we will use it in the
update.
task-3834112
closesodoo/odoo#161275
X-original-commit: 9ccd820813f6c0bd7608e80570a6999577aff513
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Context
In a previous fix https://github.com/odoo/odoo/pull/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
fixed test and conflicts in 17.0 FW
closesodoo/odoo#161014
X-original-commit: 894f981d04195861e757c052b7d10155cb5975b4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
**Current behavior:**
Entering kiosk mode in the webclient in a multi-company env
will display the logo of the default company.
**Expected behavior:**
The logo on the kiosk screen will belong to the currently
selected company.
**Steps to reproduce:**
1. Make a second company, give the default company and the new
one distinct logos
2. Select the second company from the company selector menu
3. Enter kiosk mode in the Attendance app, observe the logo
is that of the inactive company
**Cause of the issue:**
After arriving at the URL route for the kiosk page from the
_action_open_kiosk_mode() method, the context has been rebuilt
to a somewhat default state which no longer informs the current
company id. `self.env.company` references the default company of
the user.
**Fix:**
Add an id slug in the URL route which identifies which company's
kiosk we should be seeing.
opw-3802916
closesodoo/odoo#159702
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
STEP TO REPRODUCE:
=================
* Unistall hr_org_chart application
* Click on hr application
You will have an error due to the missing hiercharchy view.
closesodoo/odoo#158523
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
lase@odoo.com