The media modal's document tab has cells with icons and filenames. If
the filename was too long, it would overflow its cell, which caused an
ugly design glitch. This ensures an ellipsis on the filename when it is
too long.
closesodoo/odoo#69990
X-original-commit: 8a4f4bf04bd5e5f9cf827273ea27a189a43c2515
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In this commit, we add all the data related to the Argentinean
perceptions for each jurisdiction.
For each jurisdiction (xx) we have a new:
* Tax: Percepción IIBB xx Sufrida
* Tax: Percepción IIBB Catamarca Aplicada
* Tax group: Perc IIBB xx
* Account: Saldo a favor IIBB xx
* Account: Retención IIBB xx sufrida
* Account: Percepción IIBB xx sufrida
* Account: Retención IIBB xx aplicada
* Account: Percepción IIBB xx aplicada
* Account: IIBB xx
Also, we activate some perceptions to work with demo data
closesodoo/odoo#69873
X-original-commit: 0dcc71314d41fb30559495695f7a626b4c1b20e3
Signed-off-by: Josse Colpaert <jco@openerp.com>
Have a Fiscal position FPOS which map tax A to tax B
Have products DEMO with tax A and DEMO2
Allow FPOS in POS, Open a session, activate FPOS, sell DEMO and DEMO2
Close POS
Go to Orders, select the last one, hit return, edit, delete DEMO2 line
Tax will be wrong.
This occcur because the fiscal position mapping fail an equivalence
check with a virtual record, so the tax is calculated as A and not B
opw-2485399
closesodoo/odoo#69952
X-original-commit: 983797e626f742e84710de7ec8487824d6eaa7f1
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Usecase to reproduce:
- create a product with 0 stock
- Sale order 500 units
- a RFQ is created for 500 units
- in replenishments, you have 0 units to order, OK
- RFQ --> confirm PO
- in replenishments, now the quantity to order is 500
--> should still be 0, it leads to confusions
It happens because the replenish action check the missing
quantity for today. It result by -500 units since the delivery
is planned for the next day (default supplier lead days = 1).
But since the orderpoint exist, the quantity forecasted is
already computed correctly with the right lead time.
But the action will remove the 500 missing today from the
quantity forecasted (The idea is to add the missing quantity on
the main location. e.g. I have
-10 units in WH/Stock/Shelf1
-20 units in WH/Stock
The orderpoint will only look for its own location -> 20 to reorder
The replenishment report look by warehouse and not by location -> 30
missing. So 30 missing + 20 incomming -> 10 to add (by default on
WH/Stock)
The fix is to add a step when a product is missing then compute its
virtual available with lead days (to avoid missing confirmed moves
during the lead time).
opw-2456978
closesodoo/odoo#69527
X-original-commit: f939c7b2c4143d685c25d155a164d63070d36ed2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This revision solves two things:
- On installation of `l10n_latam_base`,
`l10n_latam_base` is set as default as `l10n_latam_identification_type_id`
for all partners in the database.
The ORM method `write` was used to do so.
With a database having a large number of partners,
such as multiple hundred of thousands,
this leaded to performance issues when `l10n_latam_base`
got installed.
I checked compute methods that could depends on this field,
and the only one I found is `_compute_l10n_ar_vat`,
which is not yet `installed/loaded` when this posthook takes place,
as it's in the module `l10n_ar` which depends on `l10n_latam_base`
and therefore is loaded after. So, it was already not executed/computed
when using the ORM `write` method before this revision.
Therefore, the use of plain SQL can be used to speed up the performance.
- Also, the ORM `write` triggered unexpected compute fields
which could raise exceptions, because of the `commercial_partner_id`
synchronization.
For instance:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1198, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 455, in load_modules
loaded_modules, update_module, models_to_check)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 348, in load_marked_modules
perform_checks=perform_checks, models_to_check=models_to_check
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 239, in load_module_graph
getattr(py_module, post_init)(cr, registry)
File "/home/odoo/src/odoo/14.0/addons/l10n_latam_base/__init__.py", line 8, in _set_default_identification_type
env['res.partner'].search([]).write({'l10n_latam_identification_type_id': env.ref('l10n_latam_base.it_vat').id})
File "/home/odoo/src/odoo/14.0/addons/base_vat/models/res_partner.py", line 538, in write
return super(ResPartner, self).write(values)
File "/home/odoo/src/odoo/14.0/addons/snailmail/models/res_partner.py", line 26, in write
return super(ResPartner, self).write(vals)
File "/home/odoo/src/odoo/14.0/addons/partner_autocomplete/models/res_partner.py", line 199, in write
res = super(ResPartner, self).write(values)
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 550, in write
partner._fields_sync(vals)
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 469, in _fields_sync
self._children_sync(values)
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 478, in _children_sync
self._commercial_sync_to_children()
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 452, in _commercial_sync_to_children
sync_children._compute_commercial_partner()
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 297, in _compute_commercial_partner
partner.commercial_partner_id = partner.parent_id.commercial_partner_id
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1127, in __set__
records.write({self.name: write_value})
File "/home/odoo/src/odoo/14.0/addons/base_vat/models/res_partner.py", line 538, in write
return super(ResPartner, self).write(values)
File "/home/odoo/src/odoo/14.0/addons/snailmail/models/res_partner.py", line 26, in write
return super(ResPartner, self).write(vals)
File "/home/odoo/src/odoo/14.0/addons/partner_autocomplete/models/res_partner.py", line 199, in write
res = super(ResPartner, self).write(values)
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 546, in write
result = result and super(Partner, self).write(vals)
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_activity.py", line 766, in write
return super(MailActivityMixin, self).write(vals)
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 322, in write
result = super(MailThread, self).write(values)
File "/home/odoo/src/odoo/14.0/addons/website/models/mixins.py", line 182, in write
return super(WebsitePublishedMixin, self).write(values)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3640, in write
self.modified(relational_names, before=True)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5786, in modified
tocompute = list(tocompute)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5862, in _modified_triggers
yield from records._modified_triggers(val)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5858, in _modified_triggers
records |= model.search([(key.name, 'in', real_records.ids)], order='id')
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1708, in search
res = self._search(args, offset=offset, limit=limit, order=order, count=count)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4492, in _search
self._flush_search(args, order=order)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4470, in _flush_search
self.env[model_name].flush(field_names)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5442, in flush
self.recompute(fnames, records=records)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5908, in recompute
process(field)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5879, in process
field.recompute(recs)
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1145, in recompute
self.compute_value(record)
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1175, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4068, in _compute_field_value
self.filtered('id')._validate_fields(fnames)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1260, in _validate_fields
check(self)
File "/home/odoo/src/odoo/14.0/addons/sale_project/models/project.py", line 70, in _check_sale_line_type
product_id=task.sale_line_id.product_id.display_name,
odoo.exceptions.ValidationError: You cannot link the order item SO/2019/11374 - [COMOD2H] Servicio de Correctivo dos Horas to this task because it is a re-invoiced expense.
```
upg-11324
closesodoo/odoo#69958
X-original-commit: 680bd481412823b66fcf45c9312a59c7029e200b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit follows https://github.com/odoo/odoo/pull/64948
Before this commit, the mail composer was not properly used. It was not started with a model and business document ids.
This commit also reverts a keyword context value for the sms composer.
closesodoo/odoo#69910
Taskid: 2342252
X-original-commit: 14629c8e1778269dc2ccc0dedd5e39b23c78669f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
The domain for the fiscal position in the carryover lines was incorrect,
missing the required quotes.
closesodoo/odoo#69921
X-original-commit: 85c07f0f93d664bf7f6028a1dfa0f663e2999c3d
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, we would compare a lang `code` (used in context) and a lang
`url_code`. For languages where those 2 are differents, the `if` condition
would always be falsy, making the canonical URL impossible to be reached.
Technically, this condition is used to get the translated name of records to
later construct the canonical URL.
Since the canonical URL will be incorrect and unreachable, the whole system to
tell search engine/crawler about translation won't work since no
`alternate/hreflang`[1] will be set in the DOM.
[1] see https://developers.google.com/search/docs/advanced/crawling/localized-versions
--------
Technical explanation:
- italian language `code` = `it_IT`, `url_code` = `it`
- belgian french language `code` = `fr_BE`, `url_code` = `fr_BE`
Install those languages on website as secondary languages.
Translate blog `Travel` to `Voyager` in french and `Viaggi` in italian.
Visiting `/fr_BE/blog/travel-1/post/post-1` will redirect to
`/fr_BE/blog/voyager-1/post/post-1` as it should, and the canonical URL will be
set to that same URL.
Visiting `/it/blog/travel-1/post/post-1` will redirect to
`/it/blog/voyager-1/post/post-1` as it should, but the canonical URL will be
set to `/it/blog/travel-1/post/post-1`.
opw-2486918
closesodoo/odoo#69918
X-original-commit: 733411fe03b924832d6b10cadf93c8fc09cc5802
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Steps to reproduce the bug:
- Try to export mail.message records
Bug:
A traceback was raised
Wrong forward-port of 69b27ac
opw:2514584
closesodoo/odoo#69912
X-original-commit: 9cf49ba3fa60c174abffc5c048616f91397f7b9d
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The "note-editable" class was lost on the editable element when loading
it into an iframe. As a result, some selectors failed, making it so that
some options wouldn't activate when they should.
closesodoo/odoo#69908
X-original-commit: d71b7d87daa5b33f16eb9c6ade29580fb2076313
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If a partner have two delivery address, one full filled, an other with missing
fields.
During the shopping (the first delivery address is auto selected), if the
partner go back in /shop/address to select the second address.
Then go to /shop/confirm_order, there no checks.
closesodoo/odoo#69901
X-original-commit: f8c8418bdd5b9d27b33fea3c63511297a231aa93
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When running an automated action on record creation, if the action
raises a UserError/ValidationError, the record will still be created.
To reproduce the error:
(Need website_crm,base_automation. Enable debug mode)
1. Create an Automated Action
- Model: Lead/Opportunity
- Trigger: On Creation & Update
- Trigger Fields: Phone (crm.lead)
- Action To Do: Execute Python Code
- Python Code:
```python
if record.phone:
raise UserError("Lorem ipsum")
```
2. On website, add a website form WF
- Action: "Create an Opportunity"
3. Complete and submit WF including a phone number
Error: An error message is displayed ("Lorem ispum"). However, the lead
has been created and is present in CRM Pipeline.
An on-creation automated action is executed once the record is executed,
but nothing will cancel this records creation if the action raises a
UserError/ValidationError.
OPW-2423948
closesodoo/odoo#69911
X-original-commit: 8d452ae16b7e6c3077d9eae135852bada43cec93
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
In an iframe, we need to make sure the element is using jquery on its
own window and not on the top window lest jquery behave unexpectedly.
This was apparent with tooltip which was called in snippets.editor with
the "wrong jquery", with the result that tooltip.js had a reference to
the top window/document instead of that of the iframe. Because of that,
it appended its tooltips to the top window instead of the iframe, and
as a result, said tooltips were wrongly positioned.
closesodoo/odoo#69879
X-original-commit: 19be8709efa8f690ccff8d04dd9a17e4ef4d82fd
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
The overlay around an image when cropping it is positioned absolutely.
If it has no relative ancestor, it will cover the entire body. This is
what happend in mass_mailing, making it impossible to scroll the page
while cropping. This commit addresses the issue by positioning that
editable relatively so that the overlay never goes beyond its bounds.
closesodoo/odoo#69878
X-original-commit: c4d423640a9f1f9892e9d24dc08531ba0bbf8887
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the colorpicker is in an iframe, listening to mouse events on the
global document can have unexpected effects. Namely clicking in the
colorpicker, then moving the mouse outside the iframe made it move the
color cursor.
This fixes that by binding it to the parent widget's document, with a
fallback on the global document in case it's missing.
closesodoo/odoo#69877
X-original-commit: 4fb33f7f8d6955a44fbb7c94c7d204e9baa09707
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
currently, Across Odoo, there are bugfix folder in around 13 module,
New manifest system allows to add new files in stable so the bugfix files are no
longer required.
after this commit,
all the bugfix files are removed from all module.and all the code in those file
is maintained as per New manifest system.
Task : 2510653
closesodoo/odoo#69830
Related: odoo/enterprise#17936
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This makes it possible to declare an element unsuitable as parent of the
tour tip via the "o_forbidden_tooltip_parent" class.
We then apply this class to the "o_we_customize_panel" of mass_mailing's
snippets menu so the tip is applied to its parent like in saas-14.2.
Without that, the tip is hidden by the body of the mail. The reason it
was positioned in the parent in saas-14.2 is that the theme selector
wasn't in the customize panel but positioned absolutely above it.
This is an ad-hoc fix to something of an ad-hoc situation, given the
relative weirdness of the html environment (the snippets menu is in the
padding of the body of an iframe).
closesodoo/odoo#69876
X-original-commit: 58d5af5df81926af1a5715dd57f6b5c3b40b1e16
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit is fixing two issues:
1: make ribbon translatable
2: display ribbon below smart button
closes#68438closesodoo/odoo#69838
X-original-commit: cbed573e6146a0aab6e0e9114be515a347cd10a4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
We need to check the selection on click in the editor's document so as
to update the visibility of the toolbar (we want to hide it if the
selection is in a non-editable area). When the editor was in an iframe
however, the wrong document was targeted: we want to check on clicks in
the editor's document, not the top document.
closesodoo/odoo#69775
X-original-commit: b0429c96e30751390991a9471a4c031dfed98d81
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Create a company whoose name ends with a dot like "Bidule Inc.", change
the company of the user to that new company, head to the Accouning
module and create a new journal of type purchase. Traceback because the
generated mail alias for that journal uses the company name and that the
local-part of an email cannot ends with a dot.
From the RFC standpoint, the local-part of an email address (the part
before the @, `john` in `"John Doe" <john@example.com>`, cannot begins
with, ends with or contain following dots.
The email sanitizing function have been updated so it takes care of the
above requirement.
See also #61811
opw-2448692
closesodoo/odoo#69864
X-original-commit: f0e840ae6db387e1dfc99cc21e09d84eb126e7b9
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
What are the steps to reproduce your issue ?
1. Install 'purchase_product_matrix'
2. try to edit a PO with more than one line
3. try to change the order of a product line
What is currently happening ?
Traceback: TypeError: Cannot read property 'data' of undefined
What are you expecting to happen ?
Change order lines without traceback
Why is this happening ?
There is a function 'reset' that checkes if 'ev' exists:
https://github.com/odoo/odoo/blob/e0af10ccc92cb3b07f0eea6fa44ebf5a1bdc86aa/addons/sale/static/src/js/product_configurator_widget.js#L119
And in 'purchase_product_matrix' there is a override of this same function that calls it
and then tries to use an 'ev' attribute without checking it before
How to fix the bug ?
Check 'ev' before accessing it
opw-2513061
closesodoo/odoo#69856
X-original-commit: 25312bc576b9e0330eb316e77d8a177ee0434832
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Task 2352493
When the user is asked to fill in the label on the invoice, the tooltip
tells him that the label can be auto-filled by configuring its products.
This leads the user to configure products. But then, as he doesn't fill
in the label, the tour is "broken".
closesodoo/odoo#69871
X-original-commit: 78b5536a4c6fa7a20d8fd182fcd85726c2a8555f
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When the payment form is displayed, Stripe.js library isn't loaded, thus preventing the customer to pay online.
When the refactor of assets was done, the link to the Stripe library was moved to __manifest__.py.
As the link does not end with '.js', the file wasn't loaded anymore.
See PR #60632closesodoo/odoo#69849
X-original-commit: 8535b090a36fe6472c4b3d8211f3be39c7f1c58a
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Signed-off-by: Valentin Chevalier <chevalierv@users.noreply.github.com>
To display an aggregate in a list view, the field format method is used.
But since mrp_time_counter that extend float_time has no format method,
you would see eg. 2.07 as aggregate and 2:04 on the line which is a
little confusing.
opw-2514634
closesodoo/odoo#69795
X-original-commit: 020958f55d384e546eb61c98763d45b5db1ed206
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
RATING
Rating texts currently have a negative skewness. Indeed apart top rating
all ratings have a negative feeling. In this commit we update them
to match more closely a 1-5 range from dissatisfied to satisfied, ok being
the middle value.
PROJECT
Filter customer rating were taking in account ratings from first e-mail
instead of current satisfaction.
IM LIVECHAT
Livechat did not catch feedbacks without comment.
Task ID-2439720
COM PR odoo/odoo#66992
ENT PR odoo/enterprise#16757
PURPOSE
We receive a lot of tickets from people who set a reply-to on their email
templates and are surprised that it doesn't work. Indeed this field is used
for mass mailing emails and templates but not in regular Chatter.
SPECIFICATIONS
Update reply-to field placeholder to "Preferred email address when sending
via mass mailing options".
Update reply-to field helper message to "Preferred email address when sending
via mass mailing options. <br> Only used when the answer is not added into
the original discussion.""
Update the no_auto_thread field label to "Reply to" in composer and introduce
a new radio button replacing the checkbox
* The original discussion (update)
* Another email address (new)
Rename fields on mail_thread and wizard: ``no_auto_thread`` should be replaced
to ``reply_to_force_new`` to ease understanding and be prefixed by reply_to.
Propagate radio keys (update and new) to mass mailing in order to have a
coherent naming (was thread and email). This naming is also coherent with
gateway naming (message_update and message_new).
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Propagate reply_to radio keys (update and new) to mass mailing in order to have
a coherent naming (was thread and email). This naming is also coherent with
gateway naming (message_update and message_new).
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
PURPOSE
Rename fields on mail_thread and wizard: ``no_auto_thread`` should be replaced
to ``reply_to_force_new`` to ease understanding and be prefixed by reply_to.
SPECIFICATIONS
For better understanding, this commit renames ``no_auto_thread`` field of
``mail.message`` model to ``reply_to_force_new``, to indicate that if the
field is checked (☑) replies should check gateway alias rules instead of
updating mailed threads.
It is also more coherent with reply_to namespacing used in various mail models
(notably new composer fields and ``reply_to_mode`` of mass mailing and mail
composer models)
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
PURPOSE
Right now, `reply_to` field on email template is misleading due to poor
explanation. This commit improves the placeholder and tooltip of the fields
to make the purpose of the field clearer especially for non technical users.
SPECIFICATIONS
Update reply-to field placeholder to "Preferred email address when sending
via mass mailing options".
Update reply-to field helper message to "Preferred email address when sending
via mass mailing options. <br> Only used when the answer is not added into
the original discussion.""
Update the no_auto_thread field label to "Reply to" in composer and introduce
a new radio button replacing the checkbox
* The original discussion (thread)
* Another email address (new)
Rename fields on mail_thread and wizard: ``no_auto_thread`` should be replaced
to ``reply_to_force_new`` to ease understanding and be prefixed by reply_to.
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
ENT PR odoo/enterprise#17941
UPG PR odoo/upgrade#2419
Purpose of this commit is to add tests related to answers through mail gateway
when having reply-to mode of mailing set to either updating existing threads
(aka replying on mailed records), either creating new threads (aka using the
reply-to alias configuration).
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
Purpose of this commit is to add tests for current behavior of ``keep archives``
field on mailing, used in combination of ``reply-to`` target (either new thread
or update existing threads).
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
In this commit we try to simplify tests organization by
* merging mailing_internals and mass_mailing tests, as they globally handle
mailing-related tests (blacklist, opt-out, gateway update through replies
and clicks);
* move wizard (mailing.test) tests in their own file as they target a
specific model;
* add some loggers to reduce noise;
* add some users wrappers to test using real users;
LINKS
Task ID-2117639
COM PR odoo/odoo#40931
Follow up on bd67479316
This test file is not respecting Odoo module dependencies.
If the module is not defined, calling `[Symbol.for("default")]` will crash.
Old require system didn't have this syntax, the similar guard was done just
before using the class.
closesodoo/odoo#69845
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce the bug:
- Let's consider two companies C1, C2 and a partner P in C2
- Let's consider an customner invoice I in C1 with P as customer
- Go to Accounting > Accounting > Partner Ledger and select I
- Click on Reconcie
Bug:
An access error was raised due to the ir.rule res.partner company
opw:2446242
closesodoo/odoo#69833
X-original-commit: 2279d84b4aefc8e488ccc33c30b816e988867589
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, There would be Traceback (AttributeError: 'bool' object has no attribute 'date')
on Confirm Receipt Date If order has no Receipt Date.
Now, Button Confirm Receipt Date will be hidden if there is not Receipt Date to confirm.
Original behavior was fixed on #60659 but attribute was replaced
here which misses this condition.
closesodoo/odoo#69828
X-original-commit: 1d680f488f68be4e6157ffd5d8d9dcbb86915ab8
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The PR https://github.com/odoo/odoo/pull/68799 tried to prevent the
form's edit button to bounce when quick editing.
The fix was wrong and some field continued to bounce the button.
This commit prevents the edit button to bounce when clicking on
any field by checking if we are quick editing.
closesodoo/odoo#69826
X-original-commit: 8393b3c51b38bd285acb91279cb08a28c241c9ca
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Right now, when o2m/m2m are set from default_get from web client,
the compute methods from the records being set yield `NewId` when
we try to get ID for the record, even if the records are existing.
It can result into wrong computation when the ids of the records
are used in preparing the data.
The same thing happens in the wizard that is used to merge mailing
lists. When we select multiple mailing lists and open the wizard
to merge them, they are set in the `src_list_ids` of wizard, but
number of recipients are always zero for them, because the method
that computes `contact_nbr` (recipients) on mailing lists fetches
data from the query, but we can't match (or find) the stats from
query result because we don't get the actual ID in recordset for
existing records.
This commit fixes the behavior by using `_origin` on the records
while finding data in the compute method, and thus getting the
correct recipient count.
Task ID-2471692
COM odoo/odoo#67213closesodoo/odoo#69820
X-original-commit: 71430334bffa4b5da3f9374c734e6231cb42a7c7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since PR #55995 is merged, we get traceback while trying to merge the
mailing lists. This has recently been fixed in odoo/odoo@fc1005aa1e .
However code can still be improved to correctly take default values from
context instead of always relying on active_ids, as well as ensuring we
are effectively working on mailing lists.
Apart from that, this commit also shortens the action name to 'Merge'
from 'Merge Selected Mailing Lists'.
Task ID-2471692
COM PR odoo/odoo#67213
X-original-commit: 58722d7e855aac75f76e48c24265130c7f03cec9
- Create Tax Exempt fiscal position
- Create Customer with Tax Exempt in fiscal position
- Enable Tax Exempt fiscal position in POS settings
- In POS, set customer to one with Tax Exempt
- Create a sale, apply, payment, validate, and click New Order
- Click magnifying glass to reprint receipt
- Default tax is automatically applied to all past orders/receipts
This occur because:
- in Pos OrderList the total is based on the amount total, and not the
actual amount paid
- the fiscal position object is not present when retrieving the order
via `selectedOrder`
opw-2485178
closesodoo/odoo#69786
X-original-commit: ffc91d4e49fd8c316de708191879563e8e59eb9a
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Antoine Guenet