On a form view:
- we open a modal form view
- in this modal we open a modal form view
- we close that second modal
=> the modal is closed and the first one is still opened, but on mobile
we can't scroll to above or below the modal.
This is because bootstrap remove .modal-open class on body when we close
the second modal, but this class is necessary to scroll (this is not
much an issue on desktop since scroll is often not necessary).
We already had a fix that was weakened in 02a063fd73.
With this changeset, we keep .modal-open as long as a modal is opened.
Without the change, added test failed with:
10. Modal is said opened (expected: true, result: false)
opw-1948423
closes#32106
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before that, the tag set on this tag for its base amount was wrong; it caused it to be reported in the wrong section in l10n_fr_reports.
closesodoo/odoo#32103
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
moment().locale('en').format('YYYY-MM-DD')
"2019-03-25"
moment().locale('ar').format('YYYY-MM-DD')
"٢٠١٩-٠٣-٢٥"
moment().locale('my').format('YYYY-MM-DD')
"၂၀၁၉-၀၃-၂၅"
Was rejected as a valid bug at moment/moment#4448
Apply the same logic than 109b319d64Fixesodoo/odoo#32081closesodoo/odoo#32102
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Onchange to show only the states of an especific country in
opportunities.
Closes#31993
opw-1958170
closesodoo/odoo#32099
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Currently doing a like then dislike does not give a void karma total. Indeed
karma is removed / added only when the vote hits 1 or -1 but does not correctly
take into account the third (void) state. We also avoid adding karma when
upvoting / downvoting an already upvoted / downvoted slide. Interface does
not allow it but avoiding to add karma at model level is always a good idea.
Karma-related tests are improved a bit.
Commit linked to task ID 1958810 and PR #32057
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose is to avoid having to recompute too much stuff. Indeed currently
slide.channel.partner completion field depends on its channel number of
slides. It means adding a slide on a channel having a lot of members will
trigger the recompute of all its slide channel information.
Instead completion on slide.channel.partner is now simply the number of
completed slides. Computed (not stored) field on channel that indicates
current user status is now based on total slide (completion / total slides).
Commit linked to task ID 1958810 and PR #32057
As we always update slide / partner relationship using sudo let us remove
unnecessary sudo in the computed field.
Tests are added to ensure it is effectively working. At least probably.
Commit linked to task ID 1958810 and PR #32057
When displaying product template list in kanban mode, all the variants
of the product template are loaded but aren't used at all. This causes a
perf issue when loaded product templates have a lot of variants.
This commit removes the field `product_variant_ids` from view
`product_template_kanban_view` to avoid that perf issue.
opw 1951369
closesodoo/odoo#32048
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The editor has a tooltip editor wizard "Change media description and
tooltip", but when selecting an image there is also a tooltip:
"Double-click to edit"
added by the editor.
The combination of the two break the functionality, eg:
- if a tooltip is set with editor, then selecting the tooltip: we see
the set tooltip and not "Double-click to edit"
- if a tooltip is set with editor, then selecting the image back, then
opening the tooltip editor => the set tooltip is lost
With this changeset, we just do not show "Double-click to edit" tooltip
if there is a tooltip set on the element.
opw-1946801
closes#32482
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Have the module 'City Addresses' installed.
Open a contact, with the city field and the zip code field filled.
Before this commit, there is a display error, the city and the zip code
are bonded. This occurs because the 'City Addresses' module override all
views with the city field. In this override the city field don't had a
CSS class.
Now, the city and the zip code are display correctly.
opw-1958175
closesodoo/odoo#32455
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, some constrains rose UserError
Which is not compliant with the api.constrains
After this commit, the constrains raise ValidationError
OPW 1949572
closesodoo/odoo#32444
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The payment token was created using the partner of the invoice,
not the one really paying the bill.
opw 1938787
closesodoo/odoo#32176
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Creating field indexes might not always be possible. For instance,
adding an index on an existing Char/Text field will fail if the column
contains values longer than 8192 bytes (PostgreSQL limit for BTrees).
Instead of failing miserably during the schema modification, simply log
the problem and continue.
closesodoo/odoo#32416
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- Set up a stockable product for which the product category is FIFO / Perpetual
- Create a PO for this product with a unit price of 100$
- Confirm the purchase order
- Receive the item in stock
- Create a SO for this product
- Confirm the SO
- Deliver the item
- Unlock the delivery order and change the done quantity to 0
- Unlock the delivery order and change again the done quantity to a positive value
A `ZeroDivisionError` is raised.
Since `move.product_qty` is still zero, we fallback to `quantity`.
opw-1963984
closesodoo/odoo#32421
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Reintroduces 5324284f5 that was reverted because in the case of an URL
like /payment_stripe/static/src/js/stripe.js directly inside a QWeb
template, we would possibly get:
/fr_FR/payment_stripe/static/src/js/stripe.js
Which is not accepted by werkzeug SharedDataMiddleware we use to serve
static data in /{module_name}/static/ directories.
Added test without changeset failed with:
- test_process_att_no_request_lang: <AssertionError>
line: self._test_att('/en_US/', {'href': '/'})
wrong result: {'href': '/en_US/'}
- test_process_att_with_request_lang: <AssertionError>
line: self._test_att('/', {'href': '/fr_FR/'})
wrong result: {'href': '/'}
- test_process_att_matching_cdn_and_lang: <AssertionError>
line: self._test_att('/en_US/a', {'href': 'http://test.cdn/a'})
wrong result: {'href': 'http://test.cdn/en_US/a'}
- test_process_att_no_route: <AssertionError>
line: self._test_att('/my-page', {'href': '/fr_FR/my-page'})
wrong result: {'href': '/my-page'}
- test_process_att_url_crap: <IndexError: list index out of range>
line: request.httprequest.app._log_call[-1],
opw-1922051
closes#32095
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Sell 4 units of a product in stock
- On the picking, create a scrap for 1 unit
- Validate
- In the immediate transfer wizard, validate
The scrap is reset to zero.
This is because the wizard overwrite the done quantity with the reserved
quantity (0.0).
If the move is already done, there is no reason to overwrite the
quantity.
opw-1958514
closesodoo/odoo#32410
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The jQuery selector is slightly too permissive, and therefore incorrect
elements may be matched. See opw for example.
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
opw-1947698
closesodoo/odoo#32149
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Because of rev. d3453f7d15
when none of the pos order lines were reconciled,
the closing of the point of sale sessions failed
because of the tax cash basis entry generation.
There is no need to create the tax cash basis entries as nothing has been reconciled.
A known case is when the the bank journal credit account is set to a receivable account,
which has as effect to fully reconcile the payment line with its counterpart,
leaving no payment lines to reconcile with the order debit lines.
This is obviously not a correct accounting configuration,
but the point of sale validation did no fail because of this previously.
Fixes#32330closesodoo/odoo#32399
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Often an invoice with the same amount is send to the same customer every week/month. If the customer pays just the amount, without any matching invoice information, common practice is to take the oldest invoice first.
Odoo currently suggests the invoice with the highest due date.
After the fix Odoo will suggest the invoice with the lowest due date.
closesodoo/odoo#32334
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This reverts commit 5324284f56
This reverts commit ad826f56ba.
If for example we had in a template:
<script type="text/javascript" src="/payment_stripe/static/src/js/stripe.js"></script>
it has been reproduced to be gotten as:
<script type="text/javascript" src="/de_DE/payment_stripe/static/src/js/stripe.js"></script>
which is unexpected and could cause an error.
closes#32090
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The field `has_tracking` should be read-only, there is no reason to make
it writeable.
opw-1958266
closesodoo/odoo#32080
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a new `product.template` is imported with `active` set to `False`,
the associated `product.product` is active.
This is not consistent with what happens in the UI: when a template is
archived, all variants are archived.
At variant creation, we keep the `active` value of the template.
opw-1955116
closesodoo/odoo#32461
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Make sure to retrieve the lang in case it is inactive. Note that a lang
cannot be deactivated if it is set on a `res.users`, but no check if
performed on a `res.partner`.
opw-1964655
closesodoo/odoo#32457
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The client IP and email are useful pieces of information for auditing
transactions, and are used by the Fraud Detection Module(s) of Ingenico.
closesodoo/odoo#32058
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
With 953a693df when a route is not found we assume it is a website.page
that can be multilang.
But with #31792 we should once again prefix URL by the language if
necessary.
The combination of the two cause issue when an url like `/web#home` is
tested since we do not take `#` into account, we check if the route is
multilang but no route `/web#home` is found => so we get
`/fr_FR/web#home`.
With this fix, `#fragment` is not taken into account when searching
route.
related to #31792
related to opw-1922051
closes#32059
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 10.0 and before, if we were eg. on website page /fr_FR/contact, if
`fr_FR` language (french) is installed and not the default website
language we would have all URL towards translated content (route with
multilang=True) prefixed with /fr_FR/ (the language code).
With 9cd982bcc some improvments were done to CDN but this also breaks
language prefixing, so this cause an unecessary redirect:
- we are on /fr_FR/contact and click on "Shop"
- we go to /shop
- odoo redirects US /fr_FR/shop
With this PR, URLs are prefixed with language once again.
note: the added test is hackish but the function tested depends on a lot
of odoo.http things that are hard to use for test (request.render,
request.context, request.httpreqest).
opw-1922051
closes#31792
Signed-off-by: Christophe Simonis <chs@odoo.com>
With this patch, `sale.order.line` records can now be created in batch,
this means that operations such as:
- SO copy
- SO create + commands
- SO import
will benefit from this patch in terms of performance.
E.g.
For a SO of 2k lines, duplicating the SO takes:
Before patch: 1515s
After patch: 171s
Creating an SO with SOL as o2m commands:
Before patch: 181s
After patch: 43s
closesodoo/odoo#32040
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
At the moment, the HS Code is only used in FedEx. This is confusing for
users, since they expect it to be supported for all providers.
We improve the tooltip.
opw-1961472
closesodoo/odoo#32445
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In a multi-company / multi-currency / multi-pricelist environment,
sending the sample SO may crash because the `company_id` field on the SO
line is not yet defined when a price conversion is necessary.
This is because it is a stored related field used in `product_id_change`
which is called programmatically at creation.
opw-1948629
closesodoo/odoo#32443
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When doing a copy, create the new translations directly in SQL and handle
potential conflicts.
Conflicts can occure in case of reinstallation as showed in opw-1955062 and
opw-1950117.
In case of "leftovers" of translations (e.g. remaining after the uninstallation
of a module), creating the new translations (when reinstalling the module) may
produce a conflict with (type, name, res_id, lang) and raise an error.
This is NOT a problem of reading .po file during installation (which handles
correctly conflicts) but of business code creating new records and linked
translations (e.g. website copying website.menu records).
Removing old translations during uninstall is handled in a previous commit in
ir.model.fields _drop_column method.
This commit fixes the reinstallation on instances with leftover translations
and fixes the issue without needing a manual intervention (i.e. delete the old
translations manually).
Closesodoo/odoo#32056
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Better than if ba58888ced as the records may be removed via ondelete='cascade'
(where the unlink is not called on the record). Will be faster too.
A solution to opw-1955062 and opw-1950117 with uninstallation of website.
Closesodoo/odoo#32056
Nicolas Lempereur