Previously, when changing the tag of a text node within a list, it transferred
the list's attributes to the newly created tag. Ideally, this should only carry
over the attributes of paragraph-related elements and not of lists.
task-3609500
closesodoo/odoo#153328
X-original-commit: 58829be8fee0d3330427a467c62280b6d6edb147
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Commit [1] changed the code in toggleList such that variable block could not be
a block. This commit updates the name of variable block to nodeToToggle.
[1]: d314fb6a6ceb6bade38a2a6b3e0e2e3fd016b7d9
task-3609500
X-original-commit: b863fff7d8e62dc28d8e5de20dffea6896dc188a
Part-of: odoo/odoo#153328
Prior to this commit, adding more than one pricelist to the available
pricelists and attempting to create a partner from the Point of Sale
would result in an error.
opw-3703269
closesodoo/odoo#153314
X-original-commit: 462ff7c657c22c29ffc2c522afdc9fd99068d6fb
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Steps to reproduce
------------------
* create the following hierarchy of companies:
```
Company
└── Branch A
└── Branch B
```
* delete `Branch A`
From then on, whatever you do will result in a Bad Request response.
opw-3662711
closesodoo/odoo#153264
X-original-commit: da803db384ec809a9c68dd379bf3c03f00d5a731
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
So far when new employee was created from applicant he got a mail
with notification about employee creation. It's not a desired behaviour
so this change makes just a log note about it.
task-3621545
closesodoo/odoo#153227
X-original-commit: 7b1dce2ef4a47870897847fb06ba8fe3cb199109
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps:
- Create an automation rule with a model X
- Delete model X (need a way that keep the rule)
Actual result:
- Crash due to warning message
Expected result:
- Warning message is logged without issue
opw-3722953
closesodoo/odoo#153078
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Steps to reproduce the bug:
- Create a storable product:
- Unit of Measure: KG
- Purchase UoM: Tonne
- Vendor: “Azure Interior” Quantity: 6T
- Recording rule: Min quantity= 500
- Trigger: Manual
- Route: Buy
- Go to the replenishment page:
- Click on the “i” icon
- On the Azure Interior line, click on “Set as supplier”
Problem:
The quantity to order is not updated to 6000 kg because in the
"action_set_supplier" function, we compare the quantity of the supplier
information with the quantity of the orderpoint without converting the
values to the same UoM. So:
500 < 6 → False
Therefore, the quantity is not updated.
Opw-3705090
closesodoo/odoo#153300
X-original-commit: 9c0550a223b155e4e0859f87d94c1229b53c824a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce issue:
1. Open CRM and select a list/tree view (opportunities or leads)
2. Select multiple records and try merging them (gear menu)
3. Click on salesperson field
4. Field dropdown contains portal users, should not be the case
Explanation:
`user_id` (salesperson field) in `crm.merge.opportunity` is a many2one related to res.users. Since it is not restricted, every existing user is listed in the selection.
Suggested fix:
In `crm.lead`, its homologous field possesses the domain formula `('share', '=', False)`.
https://github.com/odoo/odoo/blob/f987dd26e928bd0394cd0b835cc1d0fdd72e9234/addons/crm/models/crm_lead.py#L105-L108
Copying it into `crm.merge.opportunity` correctly restricts the users selection.
opw-3696148
closesodoo/odoo#153230
X-original-commit: e43d13d8aae2b46107237102e9f45a4c8e8e39df
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
Previously, In RTL mode, the table columns menu were misaligned, causing a
visual discrepancy in the UI.Now, Implemented a fix to correctly position the
table menu columns in RTL mode, ensuring proper alignment and resolving
the visual misalignment issue.
task-3695715
closesodoo/odoo#153327
X-original-commit: 331f95265f6ba04369b654811cd594cc083a54d9
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Aashish Thakur (aath) <aath@odoo.com>
To reproduce
============
- Go to shop
- in edit mode select a product
- add a ribbon or modify it
- save -> ribbon is not saved
Problem
=======
When changing the ribbon, there is no editable item that is marked
dirty, because the ribbon doesn't have a savable parent.
Solution
========
Flag the ribbon as dirty manually to trigger saving process
Note: the reason why this is needed in 16.0 and not before is [1].
Before that we did not check for the presence of the dirty flag (the
"o_dirty" class) to determine if the page has to be saved. All of this
has to be reviewed in the future, as explained by [2] and its following
commits. Note that commits like [2] is probably the cause of ribbon not
being savable anymore: parts of the DOM stopped being flagged with
o_dirty by mistake... so the saving process was not triggered "by
mistake" anymore. At the time of [1] for example: just clicking on a
product image (to maybe then add a ribbon) was enough for it to be
marked with the "o_dirty" class by mistake. This was probably solved
later... creating the bug being solved here.
[1]: https://github.com/odoo/odoo/commit/650a97d1bd59254cc2115d54d58940b6112a8d70
[2]: https://github.com/odoo/odoo/commit/e8a86b860dcba5b7782fc26c4290eee48d9fcdee
opw-3674520
closesodoo/odoo#153298
X-original-commit: 34876a321ac491c1bede1e36d0cca6248af2a86c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In the commit 671640c part of the commit 6ae9c9c was removed
inadvertently. After this commit pickup locations will be displayed when
the delivery carrier is pre-selected.
closesodoo/odoo#153259
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
1. install the calendar module
2. in General settings, add the French -or any- language
3. create a new event
4. under **Options** tab choose the recurrence type to be weekly
5. select the days to repeat the event on
6. save the event
7. send an email using the **EMAIL** button, you can notice that works like (Weeks) and the days’ names are not translated but still in English
Investigation
- the translation is applied on the model level, not on the code level. So we have to explicitly/programmatically translate the options.
Discussion
- In the proposed fix, we compute the recurrence rule `name` by translating it to the current language -the event creator's language- but as this field is **stored**, it resulted in another issue that the invitation emails sent to the participants had a mix of languages: the email template being translated in each participant's language while the recurrence rule itself is translated in the owner's language being a **stored** field
- That's why the fix got extended to embed translating of the recurrence rule directly into the template.
- However there's a **_limitation_** we couldn't deal with that's there are two types of emails we are concerned with:
- invitation emails that follows `calendar attendee` model which works correctly as discussed
- update emails that follows `calendar event` model coming from the composer which deosn't allow to properly use partners/participants languages
Resolution
- The update emails are sent in the owner's language, with the intention to enhance the behavior in master (Task-3677327)
opw-3483319
closesodoo/odoo#151669
X-original-commit: 1d6d12ab67ffc96719c3c329cdba1cc3e3471f36
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Steps to reproduce:
- Create a new purchase tax and archive it
- Create a new PO
Bug:
the archived tax is still sugested on the PO Line
Fix:
apply same logic as for sales
opw-3701429
closesodoo/odoo#153156
X-original-commit: 79e0c4383fe72b5d04af8a81b57a65044a91d273
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Currently, the user does not get any feedback if the printer couldn't print.
This can happen when the printer identifier is not the same on CUPS and on the IoT box due to this RegEx:
https://github.com/odoo/odoo/blob/5b62e301b91a3f39857c2c7f18729e10796ef194/addons/hw_drivers/iot_handlers/interfaces/PrinterInterface.py#L55
After this commit, an error message is displayed in the IoT box logs so the user is informed that the printing failed.
Also, the '-' character has been added to the RegEx as it is a commonly used character in printer's identifier as CUPS doesn't allow spaces.
opw-3458347
closesodoo/odoo#153148
X-original-commit: 722a7db800b66db2d0b735ced1b9f4074ddac611
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
How to reproduce
1. Log in as Mitchel and go to a Subscription dashboard
2. Copy the URL and paste in incognito
3. Log in as Marc (which does have access to the subscription dashboard)
--> Traceback
closesodoo/odoo#153143
Task: 3581647
X-original-commit: 1c4b6b0a491d63d1f1b6c7a21089a42d4bfd64ab
Related: odoo/enterprise#56107
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
It appears that some user need to have the german translation on the dutch
localisation. This commit will translate the following files:
- COA
- Taxes
- Fiscal position
- Tax group
- Tax report
closesodoo/odoo#151296
Task: 3682464
Related: odoo/enterprise#55207
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
If translation of '__export__' module record's source and translated value in
'en_US' language is different. In that case, record's value of en_US lang is
translated value. Also in most of the case export module records are set as
noupdate false due to this while upgrading the database to version 16 from lower
version, the record's value is changed to their source value for 'en_US' lang.
To avoid this problem of updating a record's value, this PR will not considering
'__export__' module records for translation updates. Hence,'__export__' module's
records translation remain same as per original database.
Task : 3626386
closesodoo/odoo#148757
X-original-commit: 29341902bd6b6b7ff84eede2651251f6d2ce2faa
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit fixes the problem of selection change on colorpicker fast
hover.
Before this commit, hovering too fast on the colors of the colorpicker
unselected text that would be on the edge of the selection and
uncolored. This is fixed by deep ranging the selection at the moment we
limit it to fonts. This improves the accuracy of the history as, in case
the font tag has been removed, it saves the text node as the current
selection. And since hovering updates rely on it, it prevents losing the
selection when unhovering fast (which is the cause of the bug).
We noticed two behavior when dealing with this bug. When hoving on a
color cell and exiting out of the colorpicker altogether, no bug
appears. But when switching between two cells, multiple selection issue
happen. After analysis of the performance graph, we believe that this is
due to the fact in the first case, onSelectionChange events are fired
and the handler is called, whereas in the other case it doesn't happen.
That handler particularly reacalulates the latest selection. And this
doesn't happen in our pathological case. After testing this theory, we
view that the problem is solved.
task-3295858
closesodoo/odoo#153212
X-original-commit: 9e3ee2563021b70ce64e7ec010b149820014bf8d
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Co-authored-by: Hamza Maimoune <hmai@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Previously, sanitize would remove the `<p>` tag if it was a child of an `<li>`
element. This commit makes sure that the `<p>` tag which is a child of `<li>`
with class `nav-item` does not get removed.
task-3609500
closesodoo/odoo#153211
X-original-commit: bbc980637bd104b69fcbe0452fad9be0d92288d2
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
The mega menu templates on the website, like `s_mega_menu_multi_menus` and
`s_mega_menu_menu_image_menu`, contains a `text-center` class within the `div`.
This div has multiple block type anchor nodes. When a list is added to the mega
menu, the anchor node is added inside the `LI`. Now clicking on the `A` tag then
adds the `oe_edited_link` class, resulting in the centering of the A tag due to
the `inline-block` display of the `oe_edited_link` class. This commit fixes the
issue by adding display `inline-block` when not with nav-link.
task-3609500
X-original-commit: d2d9e53b9165ab51078a9035850182132fa4a75c
Part-of: odoo/odoo#153211
Commit [1] implemented an approach to preserve all the attributes when
converting to a list. This is beneficial for `p` elements since they will no
longer be in the DOM. However, elements other than `p` will always remain,
requiring only dir attribute and not other attributes like href, data-name,
describedby, etc.. to transfer to the list.
[1]: c422db596d909efc5ae0ba049f8f9f5b80a90883
task-3609500
X-original-commit: 3b1cd38bf69cb91789d2b66070effab465a2a6c6
Part-of: odoo/odoo#153211
When inserting a list to a mega menu, the closest `LI` is a nav-item within the
navbar. We aim to prevent the toggling of this list. This commit ensures that
lists with class nav-item in the navbar are not toggled.
task-3609500
X-original-commit: a64a37aeeb5c6f6eb838cf5b9c4221e8522721cf
Part-of: odoo/odoo#153211
__Current behavior before commit:__
The `find` jQuery method calls at some point `apply` on the results.
Sometimes however the number of results can exceed the maximum number of
arguments given to a function.
In such case `RangeError: Maximum call stack size exceeded` is thrown.
__Description of the fix:__
Instead of selecting all children with `find('*')` and filter them
afterwards with the selector, we find all the elements that match the
selector in the closest `<body>` parent and then we keep only those
contained inside `$from`.
opw-3703963
closesodoo/odoo#153161
X-original-commit: 2667c8d42c5ac18257975e166a2aea254416e3fa
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
Before this commit, if a public holiday was created on dates overlapping
an existing validated leave, the timesheet entries for the public
holiday would not be created as they already existed for the leave. If
the leave was then refused or cancelled, the timesheet records linked to
it would be removed and the employee would have missing timesheet
entries for the public holiday.
This commit fixes this behavior by recreating the public holiday
timesheet records for the affected employees when refusing their leave.
opw-3550523
linked to com: https://github.com/odoo/odoo/pull/145522closesodoo/odoo#153118
X-original-commit: 47b4763ad948686e0e7155b3c0b3d0dc4d970963
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Adds a test following a fix done in odoo/odoo#143381
That fix ensured that the public leave used to
compute leaves intervals for the resources are
in the same company as the resource.
task-3668605
closesodoo/odoo#152827
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps:
- Create a draft mailing based on a theme that has the snippets menu
(the "Event Promo" theme, for instance).
- Create another draft mailing, this time based on the basic theme
("Plain Text").
- Switch from the former to the latter using the form view pager.
The editor for the basic theme record is not supposed to have a sidebar
(snippets menu), as it uses the floating toolbar instead. But when
switching between records like described above, the basic theme gets
replaced by the theme of the preceding record, and the snippets menu is
added to the UI.
This happens because [1] patched the `setValue` function to handle the
case where the element for dropping snippets (.o_mail_wrapper_td) is
missing, in particular if it gets removed via the codeview. Such fix
most likely had in mind the scenario where the codeview is toggled on
and off, but not the call to `setValue` that also happens when switching
between records via the form view pager. As a result, the html content
of a record based on the basic theme, in which such "dropzone" is
absent, is added as a child of the previous record's .o_mail_wrapper_td
element. This is certainly not the desired behavior, as it ends up
overwriting the basic theme by the one from the previous record (the
theme is defined by a class in the .o_layout div, which is a parent of
the .o_mail_wrapper_td element).
This commit, besides fixing the described issue, takes the opportunity
to add a comment with the presumed reasoning behind commit [1] and
extends the test tour in order to prevent regressions.
[1]: https://github.com/odoo/odoo/commit/9be2cb538f937645be4650af1031c8a1445bb48b
task-3573951
closesodoo/odoo#151065
X-original-commit: ed4727d922107745482dbbeb068d4bd6eba788dd
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Issue:
======
Adding a new block in mailing in email marketing raises an error.
Steps to reproduce the issue:
=============================
- Go to email marketing
- Create a new mailing
- Create one from scratch
- Drop any block
- `TypeError : Cannor read properties of null (reading 'parentElement')`
Origin of the issue:
====================
When we drop the block in the iframe's document we trigger the `click`
event but we don't have any selection yet in the document so
`anchorNode`will be `null` thus the error.
task-3724551
closesodoo/odoo#152814
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
This commit addresses a problem in CRM where it was not possible to send emails directly from the preview window.
The issue arose when returning to the chatter interface from the preview window,
as the thread object was not properly passed back (to the chatter).
This fix ensures the thread object is reintegrated into the chatter interface, resolving the email sending issue.
Issue was traced back to the commit
5d99de10ec [FIX] mail: do not reload chatter when not needed
https://github.com/odoo/odoo/commit/5d99de10ec09244e10e4130573ad2e0c38e8600
[reproduce]
- install crm
- create activityTypes AT with an email template specified( crm/configuration/activityTypes)
- open a Lead, ( crm/sales/MyPiepline)
- schedule activity with activity type AT
- click "preview" on the activity
- click "send" or just close the preview -> BUG traceback
opw-3680600
closesodoo/odoo#152698
Signed-off-by: Andrzej Pietrusiak (pian) <pian@odoo.com>
Versions
--------
- 15.0+
Steps
-----
1. Go to product variants;
2. select a product;
3. add a new Vendor line in the Purchase tab;
4. save;
5. add another Vendor line;
6. save.
Issue
-----
Previous line disappears from view.
Cause
-----
In 93bc96047ff684cb66b69186822493815cf37982 I added logic which sets
the `product_tmpl_id` in `product.supplierinfo` if a `product_id`
gets written without accompanying `product_tmpl_id`. Adding lines from
the Product Variant views add `{'product_id': False}` to the values for
every vendor in the list without a Product Variant, so their
`product_tmpl_id` gets overwritten with the `product_tmpl_id` of an
empty product.
Solution
--------
Only overwrite `product_tmpl_id` iff `product_id` gets written to a
non-falsy value by changing `if 'product_id' in vals` to
`if vals.get('product_id')`.
opw-3664524
closesodoo/odoo#153168
X-original-commit: 03d4be7b8804863a7e7e9af29a8ec61c65d6dab3
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Levi Siuzdak <sile@odoo.com>
When using Peppol Bis 3 with a partner without VAT, use the
`peppol_endpoint` to fill the `PartyTaxScheme/CompanyID` and
`PartyLegalEntity/CompanyID` to avoid errors like:
"[BR-E-02]-An Invoice that contains an Invoice line (BG-25) where the
Invoiced item VAT category code (BT-151) is "Standard rated" shall
contain the Seller VAT Identifier (BT-31), the Seller tax registration
identifier (BT-32) and/or the Seller tax representative VAT identifier
(BT-63)."
"[BR-CO-26]-In order for the buyer to automatically identify a supplier,
the Seller identifier (BT-29), the Seller legal registration identifier
(BT-30) and/or the Seller VAT identifier (BT-31) shall be present."
Also adapt the tests, as the rules for the supplier's identifier are
stricter than for customers.
closesodoo/odoo#153046
X-original-commit: 2044a11dd6ec493eb020b6067cad1d216e565687
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Steps:
- Install project module
- Activate customer rating from settings
- Create new project with out company
- Add stages, then in final stage set in rating email template
to 'Project: Task Rating Request'
- Create a task and move the task to that final stage then
- Check the emails in settings, the subject line is look like
': Satisfaction Survey'.
Issue:
- When there is no company set on the project, on that time company name
is missing in subject line.
Cause:
- In task satisfaction survey email template only set the company
name based on the project only.
Fix:
- By adding the current user's company name to the template subject line,
the problem will be solved.
task-3626702
closesodoo/odoo#153103
X-original-commit: 8cf35cb51d97c0259e98765f899e3f2f8b98f52e
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
According to https://docs.python.org/3.7/library/xmlrpc.client.html :
When passing strings, characters special to XML such as <, >, and & will be
automatically escaped. However, it’s the caller’s responsibility to ensure that
the string is free of characters that aren’t allowed in XML, such as the
control characters with ASCII values between 0 and 31 (except, of course, tab,
newline and carriage return); failing to do this will result in an XML-RPC
request that isn’t well-formed XML.
This commit implements the removal of control characters from strings. As we
convert binary data to a string and return it, the resulting string should not
contain forbidden characters neither. The modification of dump_unicode function
now fulfills this requirement and can be applied to dump_bytes, contributing
to a more consistent behavior overall.
steps to reproduce:
- create a product with an ASCII control character in its name (ex: \x03)
- read the product name using XMLRPC
before this commit:
- client can't parse the response, an error is raised
after this commit:
- we make sure the string is free of those characters
opw-3617458
closesodoo/odoo#153084
X-original-commit: 3fa92ff58daef0dd2464beadeafef208871deca6
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
This commit fixes an issue caused by the way we use onInput props in Knowledge to
fetch articles depending the current search value. Since we start from an empty
string in the input again, it make no sense to display the choices previously
fetched with a search value no longer displayed in the UI. The only way to display
the correct items is to update the input value, then put an empty search to fetch
accordingly.
This is clearly an issue, when the onInput props is used to fetch the content of
the SelectMenu, depending of the search value. The UI obviously display an empty
search, and filter accordingly, but without fetching the items corresponding to
the empty search value.
A test was added as well to assert SelectMenu can be used for this purpose without
forgetting to call onInput again when clearing the search value in beforeOpen.
closesodoo/odoo#153072
X-original-commit: ca417f171b1bd2dd567beed7bc0e1fcaba6c8a4c
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
This commit fixes the style applied to the o_select_menu_sticky elements. Since the
fix from commit (1), the text cursor is shown when hovering those elements. This was
without considering the fact that this class is mainly used to display elements on
top of other elements of the component.
This includes usages with the bottomArea slot, that can be used with a DropdownItem.
Because of the changes from the commit previously named, the focused color was no longer
applied, and it was showing the wrong cursor when hovering.
1) 53466e152bb819524b2890866bea4cbdd9091275
X-original-commit: 8ecc6f2a960494f01a745f21a24c3cc57614ad86
Part-of: odoo/odoo#153072
Do not take into account "retención" type taxes in the sum of the total price of the invoice lines,
these taxes are of retention types and are declared in RetencionSoportada XML node.
Add amount_retention in invoice values and change template_invoice_factura to activate RetencionSoportada xml node.
Before this commit:
Invoices with "retención" type taxes are not declared correctly, validation errors in the response of the tax agency.
With this commit:
Invoices with "retención" type taxes are declared correctly and accepted with no validation errors in the response of the tax agency.
closesodoo/odoo#152978
X-original-commit: ff961775d7f175c4f71f33f9b3955c04a234db55
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
- Create a product with two variants A & B
- Create a BoM for this product and create the following operations:
-- ope_A that applies only on variant A with a duration of 10
-- ope_B that applies only on variant B with a duration of 30
-- ope_common that applies to both with a duration of 60
- Set an employee cost (e.g. 120) on the chosen workcenter
- Open the Overview of the created BoM
Issue:
The column 'BoM Cost' will be completely incorrect, as the `zip()` will
try to associate all operations on the BoM (including operations that
doesn't apply to the selected variant) with all operation lines
generated for this variant (already filtered).
This will end up trying to add the wrong duration costs to the wrong
operation line on the report.
Instead, we can simply compute the value once and override its
computation in `mrp_workorder_hr` to include the employee costs.
closesodoo/odoo#152901
X-original-commit: 04b5b5d45265de0cf374c1295a679f38febfe5ca
Related: odoo/enterprise#55973
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Current behavior:
The column : "To Consume" is not aligned with the values.
Cause of the issue:
There is an html anchor with a t-else close that should not be there.
Fix:
This anchor is removed.
opw-3692098
closesodoo/odoo#150891
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
After the commit added by odoo/odoo#152513, it was not
possible anymore to create a new time off from the
management view in situation where the default leave type
wouldn't be defined.
This commit adds a falsy value so that the variable exists
even if no default leave type is set.
closesodoo/odoo#153066
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
**Current behavior:**
Confirming a sale order containing an order line associated
with >1 products which are tracked via serial number creates a
single repair order.
**Expected behavior:**
A repair order for each individual product in the line is
created.
**Steps to reproduce:**
0. Create a storable product which is tracked via serial number
and has create_repair set to True. Update on hand stock so
there are at least two available and assign them each a
serial number.
1. Make a new sale order with one order line for that product
with the product_uom_quantity equal to the quantity
created in step 0
2. Confirm the order and open the newly created repair order
3. Select a serial number for the repair order, start the
repair, then end the repair to raise the exception
**Cause of the issue:**
Multiple products will be associated with one serial number. In
stock_quant.py, the check_quantity() method checks the quantity
of product_ids associated with a particular lot_id and
location_id. In this instance, quantity will now be >1 which
results in the ValidationError exception.
**Fix:**
Make a discrete repair order for each product in the order
line when the product has serial tracking. This is more logical
than asking a user to select one serial number for many
products.
opw-3688072
closesodoo/odoo#151041
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
ba1a550#diff-36973ac6e1f20b32a00fbcdc1f811c923bbb44ca15a0e068018e904ff565644fR97
The previous PR added some constraints on what can be used on the
context of views. The key word 'force-email' is no longer relevant and
will be removed from the context before reaching the next view/python
code.
This commit's purpose is to remove the force_email that were forgotten.
In order to still open the simplified partner form view, the ref of the
view is given in the context instead. While at it, we also fix the
create option given on the partner_ids field that was inconsistent.
affected version 17.0 - master
task - 3538000
https://www.odoo.com/web#id=3538000&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form
Please enter the commit message for your changes. Lines starting
closesodoo/odoo#149806
Related: odoo/enterprise#54549
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since [1], the websocket worker is started when a transient thread is
added to the mail store. This occurs because this PR introduced a call
to the `addChannel` method of the bus service when the current user
was not member of the thread.
Since transient threads are not yet created, they have a partial state
that does not necessarily include channel members hence the impression
that the current user is not member of the channel.
This PR prevent starting the bus service for transient threads.
[1]: https://github.com/odoo/odoo/pull/146800closesodoo/odoo#153000
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit:
After commit f7147b36da0b3963e5bafb09cb585f130dcbfcf0
on changing partner gst treatment, it makes GST treatment
on posted invoice False
After this commit:
It resolves the issue due to commit f7147b36da0b3963e5bafb09cb585f130dcbfcf0
closesodoo/odoo#152997
Signed-off-by: Josse Colpaert <jco@odoo.com>
Restrict collaborator portals to:
- Change unallowed fields on subtasks
- Create/Update/Delete tags.
They can only link, unlink tags to tasks.
task-3698146
closesodoo/odoo#152992
X-original-commit: 32c21d651c32c978f3cf67105e1c2eca9de2334d
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit:
When creating a nested checklist within another checklist and subsequently
changing the direction of the parent list, the direction of the parent element
would reverse alongside the pseudo element. However, in the case of nested
checklists, only the content's direction would change, while the pseudo
element's direction remained unaffected.
Afte this commit:
When altering the direction of the parent checklist's content, both the content
itself and the associated pseudo element's direction is changed alongwith the
nested checklist.
task-3461806
closesodoo/odoo#152890
X-original-commit: f46e1f0c5b00f2e289feef5e35f3fea6fb477104
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Avoid specific changes of l10n_in invoice report to affect other
countries.
OPW-2504287
closesodoo/odoo#152862
X-original-commit: 87a1fa6f49f1dc1824cfcdc2701d92d0382fa652
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
When user gives wrong domain in any account report of report line and tries
to access the same report similar error is generated.
Steps to Produce:
- Install 'Accounting'
- Go to Accounting > Configuration > Accounting Reports
- Open any account report and click on add a line
- Now add a line in the report line
- Create an expression select 'Computation Engine' as Odoo Domain.
- In Formula add this domain [('code', '!=like', '620.%')]
- And add Sub-Formula as 'sum'
- Save the expression and also the report
- Go to Reporting and select the above report
Traceback will be generated
ValueError: Invalid leaf ('code', '!=like', '620.%')
When user applies invalid values in domain or invalid domain format it leads
to the traceback because of this line:
https://github.com/odoo/enterprise/blob/16.0/account_reports/models/account_report.py#L1510
sentry-4358342635
closesodoo/odoo#152910
X-original-commit: a41c9ef79a71230422eeb6c561f7f217c513bb30
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce:
- Install `crm` module (for test purpose)
- Create a new lead
- Set an email address, phone number, company name and contact name
- Save the lead
- In the chatter, send a mail (with the default recipient checked)
Issue:
- The partner has only the email address set (also set as name).
- The `contact name` on the lead is updated with the partner name
(who is the email address).
Cause:
When sending a mail with the default recipient checked, the partner
is created based only on the email address (therefore, name is same as
email), and when assigning the new partner on the lead, the
`contact name` is updated with the partner name (who is the email
address).
Solution:
Alter the route `/mail/partner/from_email` and `/mail/message/post`
so it can take or manage additional values for the creation of the
partner.
opw-3512045
closesodoo/odoo#152780
X-original-commit: 92916985b72ff1cda2021900f0aa9476f7283576
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Google has removed the feature that allowed sitemap submissions. Now,
it's standard practice for Google to crawl the /sitemap.xml. This commit
permits to show a notification message when the user clicks on the
button to submit a sitemap.
task-3323849
closesodoo/odoo#152700
X-original-commit: fb842f682bb8b2600d861a5e0bb92503857bd2de
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Deependra Solanki