Use of '_for_xml_id' instead of read in order to avoid
access right issue on 'ir.actions.act_window'.
closesodoo/odoo#60946
X-original-commit: 4e65fbf14491ea97415ede6d10385222c8d4d074
Signed-off-by: ndeodoo <ndeodoo@users.noreply.github.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Show a nice error message when starting negative transactions on Adyen
terminals.
opw-2368978
closesodoo/odoo#60985
X-original-commit: 4dc790629e49c6e78a009fde3a22915944bb5583
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Issue
- Install "Accounting"
- Go to "Accounting Overview/Invoices"
- Switch to kanban view
Cause
The wrong field ("journal_id") was present instead of "partner_id"
Solution
Change with "partner_id"
opw-2367738
closesodoo/odoo#60970
X-original-commit: e4ac9891450d96149551d19ac2d2f74f410f877c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
- Some tax_base_amounts checks were missing
- The type of repartition used to generate tax lines was not tested; it made the test confusing (as in this case, sales taxes invert their tag, given here the impression the wrong repartition was used, and potentially shadowing a bug)
closesodoo/odoo#60966
X-original-commit: c703b3a2f5a2d4d8bfbf0bc14203dde1b1bdec23
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
- The field 'invoice_ids' no longer exists on account.payment.
- When registering a payment using a payment token, the payment is not posted directly but the payment transaction is processed instead.
It means the payment is not posted until the CRON call. Since 14.0, the journal items can't be reconciled if not posted and then, we can't wait the CRON to update the payment state.
- The payment token is no longer available when registering a payment for invoices.
closesodoo/odoo#60918
Task: 2352628
X-original-commit: 0ad8979cb345805b7b1bdc330621b42e1d625593
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
In order to ease the usage of lazy translation, add the possibility to
add the _lt objects together and with strings.
Adding two _lt objects together or to a string will execute their
translation, so these operations still must be done once the user's
language has been defined.
For example, this is now possible:
MESSAGES = {
1: _lt("Hello, world!"),
2: _lt("Lorem ipsum"),
}
def get_text(code):
return _("Text is: ") + MESSAGES[code]
closesodoo/odoo#60844
X-original-commit: c4596664e5514018c565eaf14b93e000d972bd30
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
- Activate stock locations
- Go to Inventory > Configuration > Locations
- Click on the 'Products' stat button
The filters `real_stock_available` and `real_stock_negative` are not
applied although they are in `search_default_`.
This is due to c1f7987f49 which refactored the various search
views of products.
The solution is to add the `search_view_id` in the action. However:
- `<act_window>` doesn't support it
- `<act_window>` is deprecated in 14.0
Therefore, we convert the `act_window` element into a regular `record`
and add the appropriate `search_view_id`.
opw-2371962
closesodoo/odoo#60942
X-original-commit: 9677128c42761123e59fa8187a59864eb89f06e8
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Use the tax tags returned by the compute_all for the base lines instead of recomputing them separately
Splitting the computation caused inconsistent computation in some cases between the base and tax lines (one could select the refund distribution, while the other selected the invoice one).
- Pass the is_refund parameter to True if either the quantity or the price is negative (but not both)
Those negative lines should correspond to refund repartition (double-checked with the Belgian tax report in v12).
OPW 2351412
closesodoo/odoo#60925
X-original-commit: 7827581b208b464638a91044462d0bc497025326
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
In current Debian version (0.19) ofxparse gives the following warning:
ofxparse/ofxparse.py:40: DeprecationWarning: Using or importing the ABCs from 'collections'
instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working
return isinstance(candidate, collections.Iterable)
Since we can't do anything about it, we filter it for now.
ofxparse already fixed it https://github.com/jseutter/ofxparse/issues/155
A Debian bug report has been opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973055closesodoo/odoo#60880
X-original-commit: 00497c03db080914fed81dc3fc66fa5d45f65a4e
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Thomas Dieuzeide <tdi-odoo@users.noreply.github.com>
In the purchase page of the product form, show Delivery Lead Time by
default.
Task 2357198
closesodoo/odoo#60923
X-original-commit: d107532fb65c9dd78a82c16646d0659a49495ec6
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Currently the delivery date on PO line will always be set to today if
there is no receipt date on PO, which makes the delivery lead time not
working. Fixed this issue in this commit.
Task 2357198
X-original-commit: 147aa4c67fb912a2e62dd8be1fc770db258e28d0
Before this commit, with an opened DropdownMenu component, when the user
clicks on a Bootstrap's dropdown the DropdownMenu doesn't close.
This issue is due to a conflict between the global click listener
registered to close the DropdownMenu and the listener registered by the
Bootstrap dropdown:
the last one prevents the event from bubbling up to the `window` element
and be handled by the first one.
This commit fixes it by enabling the `capture` flag on the DropdownMenu
global click listener, giving it the opportunity to handling it properly
and close the DropdownMenu.
Note: this commit also fixes an issue when a dialog is opened from a
DropdownMenu (like the favorite's delete action) and prevents it from
closing in the background (e.g. when the dialog is still opened).
opw-1879566
closesodoo/odoo#60928
X-original-commit: 7f1bcc8ceb78729725f65585e923b08f94bf75b5
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Before this, misc operations always used the balance of the base line as the tax_base_amount of the tax line. This was inconsistent with the invoices, for which we invert its sign when making a sale invoice or a purchase refund (as for those operations, positive amounts are put in credit). This commit should make everything behave in the same way.
closesodoo/odoo#60912
X-original-commit: 2ca3158ce2de596526067dbd86da2ef7d4ae85bd
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this commit, the state of the composer was not properly saving
its state when focusing out, which caused erroneous composer states
in some corner cases, like when posting messages on mobile in some
browsers. This commit fixes this issue.
opw-2366374
closesodoo/odoo#60913
X-original-commit: 8e79fefdb9990a6480fdae2684e07799e5439b06
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Don't delay the insert of partners or channels until it actually takes too much
time.
Don't await `_initMentionPartnerSuggestions` as it is just nice to have.
task-2371485
closesodoo/odoo#60911
X-original-commit: e78805fc3ae9b5dbbf72667e5bd62e5c5346cc53
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
- Create 2 warehouses A & B
- In the website settings, set the `inventory_availability` as `always`,
but do not set a warehouse
- Create a Product P, make some stock in warehouse A
- Create a Product Q, make some stock in warehouse B
- Publish the products
- Go to `/shop` => both products have availability
- Add P in the cart => it works
- Add Q in the cart
Error: 'Some products became unavailable and your cart has been
updated...'.
This happens because the availability is checked on the warehouse of the
SO, not the warehouse of the website (not set in this case).
opw-2361768
closesodoo/odoo#60895
X-original-commit: 6b05fb2b21a3b58cfef3f280941d985eec158b78
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
* Analytic defaults keep their old value
* The date_maturity is non-sense, it isn't set on lines needing analytic
* Analytic default should work for misc. operations too, but only for
product/service lines on invoice documents.
closesodoo/odoo#60904
X-original-commit: 4d2b8dd1bef40c592215728fab6c31f192176e93
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Purchase
- When a RFQ is in "To Approve" stage, on the printed pdf, keep "Request for Quotation" as a title
- "Send Reminder" action should open the composer when triggered manually.
Inventory
- In tree view of transfer, set date_done optional = hide
- In (mobile) picking view, replace button text with 'add a product'
- fix Vendor Group by in Replenishment report
- Warning message when changing product tracking from untracked to tracked
MRP
- Reporting > Manufacturing Orders : change measure for total quantity grouped by scheduled date = month and by product
- Reporting > Work Orders : change measure for Duration per unit grouped by workcenter and by product & add unit (minutes)
- Reporting > Overall equipment effectiveness : group by loss reason added to the current group by workcenter
closesodoo/odoo#57036
Related: odoo/enterprise#12926
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When the test starts after 00:00:00 UTC, the test fails.
closesodoo/odoo#60891
X-original-commit: c62acb48ac3ae11180a6817321664fb01833d3bd
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When an event is registered during the tour, a link is clicked without
waiting for any result.
As a consequence, the tour stops and the browser cookies are cleaned.
This leads to random failures because sometimes the remaining requests
generated by the link click have enough time to be completed and
sometimes not.
With this commit a simple step is added, that waits for the clicked link
page to be loaded.
closesodoo/odoo#60885
X-original-commit: b261ab598c7a18bbe6590114aa171d61ea9c2767
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Fine-tune of #59524.
If the delivery address doesn't have any delivery method assigned, you get an
undesired change of behavior: no delivery method is populated in that cases.
Note that the delivery method is not a commercial field that is propagated from
parent to children.
With this patch, we get a very similar behavior, which is fallbacking to the
commercial partner's delivery method if there's no delivery method in the delivery
address.
The only different behavior will be if the order partner is different from the
commercial partner of the delivery address.
closesodoo/odoo#60881
X-original-commit: 682b2e6c214b73f67e849df927bd4bda0af31d5a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
we need to pass empty context so it can be overriden in session.js. we should be
able to not specify any context and let session handle it.
SPECIFICATION
- removed empty context from thread rpc
- as there is already managed empty context in session, so no need to manage
empty context in rpc
LINKS
Task 2243187
PR https://github.com/odoo/odoo/pull/54512closesodoo/odoo#54512
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The 'Mark as lost' server action raises an AccessError when executed by
a non administrator.
Due to de4213b771
opw-2371490
closesodoo/odoo#60866
X-original-commit: b80e44bac5de3ccffad42917307bb5f049a7bec6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When we want to upgrade the IoT box to the lastest version
we need install kpartx to the third partition.
However the source are not up to date and we can't fetch
the package.
So we must update this partition before fetch the package
X-original-commit: 83ec693cc2c4b92b29cdee6f63b283655c2633df
m
X-original-commit: f486e61c36cb39b7b79faf018f5b8ac0448e284c
m
closesodoo/odoo#60655
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Closing the Authorize.net popup with the little "x" doesn't call the
responseHandler. Looking at the documentation (and source) of
AcceptUI.js it seems there's no clean way to detect this.
Because of this the "Pay & Confirm" button remains disabled, requiring
the user to refresh the page.
To solve this don't disable the button at all. Presumably it was added
to avoid issues when spamming the button with clicks on a slow
connection. But simulating this with a slow connection doesn't cause
any issues.
When AcceptJS is not yet loaded it's loaded with web.ajax.loadJS(). It
correctly handles parallel calls before loading is finished and
returns the same promise. AcceptJS correctly ignores subsequent click
events on the button, because it immediately blocks all clicks on the
body (and grays it out).
Using a MutationObserver was also considered but this approach is much
less messy.
opw-2367166
closesodoo/odoo#60870
X-original-commit: 63f759b63284efc5fb9f5dc7dfbe4e2aed982ad0
Signed-off-by: jorenvo <jorenvo@users.noreply.github.com>
The custom vat index name matched the name that the system uses for automatic
indexes (when a field has `index=True`).
But the `vat` field was created with `index=False`, and this means that the
ORM would execute a `DROP INDEX IF EXISTS res_partner_vat_index` when updating
any addon that touches the `res.partner` model. Since this model is so
ubiquitous, this resulted in a ton of unnecessary `DROP INDEX` + `CREATE INDEX`
queries when updating any database.
What's even worse is that dropping or creating an index needs a complete
semaphore lock of the whole table, so if you're updating a high-traffic HA
production instance while it is running, you have a very high rate of concurrency
failures, because almost everybody is going to be using the `res.partner` model
in some way almost all the time.
A deeper investigation reveals that the index itself was useless. It was added in
a6e1eb9 and apparently meant to be used for optimizing name_search(). But even
though a6e1eb9 modified name_search(), it did the substitution in Python[1], so
in practice the database had no way to recognize the pattern and never used the
index. The specificity of that index makes it useless for other cases too, so it
can simply be dropped to save space.
Further, considering that the `vat` field is a common search criterion, it
actually makes sense to enable a normal index on that field, by setting
`index=True`. Neither dropping the index nor creating the default one has any
impact on existing databases, so it's safe in a stable series. A new
installation or a forced update will be necessary to benefit from the changes.
~~Finally, because the bad custom index had the same name as the regular one, an
upgrade script is foreseen to drop the old one before letting the ORM re-create
it properly.~~
Fwd-port note: the upgrade script and version bump were reverted as a
consequence of the unforeseen consequences in #60771.
1: https://github.com/odoo/odoo/blob/a6e1eb9f0ad285fac7d0ca0b9f89f046d78ec9c7/odoo/addons/base/models/res_partner.py#L710
@Tecnativa TT26303
Closes#60346
See also: #60771closesodoo/odoo#60862
X-original-commit: 2f4a7de3d25cec36ac3b85e3f33122728346c206
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Issue
- Install "CRM"
- Create new lead
- Set X to customer
- Send a log note
X receives log notes by mail
Reproducible on Project and CRM
Cause
The customer sends a list of partners who will receive an email
even when it is a log note
Solution
Send the list of partners only when it is an email and not a log note
opw-2369280
closesodoo/odoo#60855
X-original-commit: 4e660dfdf40a36eed7123bcea2452874238fddd8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Take argument _action_ of method _verify_request_recaptcha_token into effect.
Otherwise it always sends 'website_form' as recaptcha action to google
recaptcha service to verify the token, this would lead to failure.
closesodoo/odoo#60854
X-original-commit: f29a625857128617c2d4d795e648d5ad1f7ab8a4
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Install account / purchase / sale
- Ceate an internal user without any access rights
- Go to `/my`
A 500 error is raised because of an AccessError.
When the user has no access rights to any of the mentioned applications,
the `search` call returns an AccessError.
We prevent the access error and return 0 as a fallback.
opw-2367559
closesodoo/odoo#60849
X-original-commit: 54ef98c613219aba3bda41817f7767261b8092d2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Prevent crash in case `base.default_user` has been deleted.
Note that the user shouldn't be deleted in a first place, but that's
another discussion...
opw-2360615
closesodoo/odoo#60821
X-original-commit: 7342cadcfe8d85edb8a53aef0ecc402dbbc7e935
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this patch, adding a field on a custom model discards all
automated actions on that model. The explanation is relatively simple.
When models are set up in the registry, the classes of custom models are
dropped then recreated. Given that automated actions are implemented as
monkey-patches on model classes, the setup of models simply loses those
monkey-patches, which explains why they stop working on custom models.
The fix introduces an `_unregister_hook()` method, that is expected to
clean up what has been done in `_register_hook()`. When the registry is
ready (i.e., not being loaded), the setup of models first invokes
`_unregister_hook()` on models, proceeds with the setup, and finally
invokes `_register_hook()` to reinstall the hooks.
OPW 2362308
closesodoo/odoo#60833
X-original-commit: 67152bf82da2674179297d32e4cec9dd534fa0c9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
PURPOSE:
It often happens that someone will send you a message, but you don't actually
know who is the person within the company. In this context, it would be
practical to have direct access to that person's public user or employee form
in order to get more information.
SPECIFICATIONS:
on hover, display the name of the user is bold + underlined
if the user clicks on the name, redirect to:
- the employee form if the hr module is installed and if the user is
linked to an employee
- else redirect to the partner form
LINKS:
closes https://github.com/odoo/odoo/pull/58754
task 2252924
closesodoo/odoo#58754
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
To reproduce:
1. Start with empty instance with point_of_sale (no demo).
2. Install Indian localization from Invoicing.
3. Start a pos session with that config.
4. Sell a product.
5. Assign a customer to the order.
6. Invoice the order during payment.
7. Validate. [BUG] Empty receipt is shown in the receipt screen.
This is because of empty country field of the pos.config's company.
We modify the check for country code in the receipt template to
account for empty country as fix.
closesodoo/odoo#60814
X-original-commit: 86423e2da90e1d023bd616cbc719c80f087a4206
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
User is not allowed to save an empty name for the customer details.
If tried, an error message is shown. This feature has been accidentally
dropped after the pos-owl-refactoring. We are restoring this behavior
in this commit.
closesodoo/odoo#60813
X-original-commit: 025d2c9685af74f7ef00530966cb5fb306a31085
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Joseph Caburnay (jcb) <caburj@users.noreply.github.com>
PURPOSE
Improve ui in CRM settings to ease user understanding and using settings.
SPECIFICATIONS
This commit re-organizes some crm related settings groups for better
usability by interchanging their positions and by putting related
groups together.
Crm PLS warning improvement: https://tinyurl.com/y67ug3fr
* Reword PLS explanation and button (followup of 9a57a7edfb)
Settings cleanup: https://tinyurl.com/y5lwqwe6
* Move "Leads" option on the right, next to Recurring revenues;
* Move "Incoming Emails" below "Leads";
* Switch "Visits to Leads" and "Outlook CRM Extension";
LINKS
TaskID - 2351582
closesodoo/odoo#60264
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Change the logic of the KPI "Day-1" to "Last 24 hours", so new freshly
created data in the free trial are included in the statistics (same for
last week and last month logic). This requires to change from date-based
computation to datetime-based.
Change the URL of the "connect" button from "/web/login" to the root
URL (so the user is not stuck if he didn't activate yet his database).
Task ID-2359406
closesodoo/odoo#60166
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Each time the function is called, we append to the same persistent object.
closesodoo/odoo#60808
X-original-commit: d8790cce3e4a23d2b6b1c32d48d5df14fbdcfd33
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
365 * 24 * 60 is not a year, but year/60 ;)
While we fix it, it is the good time to change and use the dedicated
http.STATIC_CACHE_LONG that exists for it.
closesodoo/odoo#60807
X-original-commit: bb4d5bebaf926cbdf6f8842cd1ca0e5850523bf5
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
If you don't install website_event_meet_quiz or website_event_meet_quiz,
the route will not have sitemap defined.
Now we force the sitemap to False by default.
And let the override choose the presence or not into the sitemap.
It will remove the warning, if your are running test only on website_event
No Sitemap value provided for controller <bound method EventCommunityController.community of
<odoo.addons.website_event.controllers.community.EventCommunityController object at 0x7ff889bd3668>>
(/event/<model("event.event"):event>/community)
closesodoo/odoo#60806
X-original-commit: 7c7c40f6248b15274afd0cd75d0be28d1ccb1e8f
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Create SO 1:
- Section A, sequence 10
- Product A, sequence 11
- Create SO 2:
- Section B, sequence 10
- Product B, sequence 11
- Select both SO
- Create the invoice
The resulting invoice lines are organized as follow:
- Section A, sequence 10
- Section B, sequence 10
- Product A, sequence 11
- Product B, sequence 11
This is obviously not expected as it messes up the organization of the
lines.
This happens because the sequences of the SO lines are kept at invoice
creation, while it is necessary to resequence the invoice lines to keep
them organized.
To do so, we loop on the invoice lines before their creation in order to
assign a sequence corresponding to the order in which they have been
added in the list. Since the invoice lines are added one SO after the
other, this allows us to keep the appropriate ordering.
Note that we only resequence if there are less invoices to create than
SO, meaning that several SO have been merged. Indeed, in case a single
invoice is created from a single SO, there is no need to resequence.
This assumption is not completely true: if not all selected SO were
invoiceable, the number of invoices created is also smaller than the
number of SO. However, resequencing should be safe so in the worst case
we might resequence an invoice while it was not necessary.
We also leave the possibility for third-party addons to alter the
resequencing thanks to the `_get_invoice_line_sequence` method.
opw-2363443
closesodoo/odoo#60789
X-original-commit: 97c2f5ea51a669830b3e6d6d2d7d857742a41481
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Nathan de Pryck