In stock.move.lots.form view, the field product_uom must be readonly like
the field product_uom_qty.
When creating a raw material, it was not possible to add a stock move line
with a finished product for a product which is not tracked.
The consumed field must be readonly in mrp_production_form_view view to avoid
to send to the server wrong value manually set.
opw:1861321
As a follow-up to commit 276ea817f4,
we change the default template database used for CREATE DATABASE
operations, and we avoid setting the LC_COLLATE option unless
this default template is used (to avoid locale compatibility errors).
Rationale for the default template choice:
PostgreSQL uses `template1` by default, and recommends that users alter
`template1` if they need a custom template, while keeping template0
virgin. This is likely to be the reason why we had `template1` as the
default previously (from a1e5c645d9).
However, for new Odoo databases, it's actually better to use `template0`
as template, for multiple reasons:
- We do not customize the template database, and the system will work
fine when starting from a completely virgin database
- Since template0 does not allow connections by default, we have a
stronger guarantee that no user will be connected to the template
database (which would otherwise block database creations!)
- We use the same logic for creating new databases and for creating
placholder databases for restoring dumps. In the latter case,
PostgreSQL recommends using a virgin template, to obtain a perfect
copy of the database being restored (unaffected by any template
customization)
- Using `template0` as a template lets us choose any encoding and locale
settings (LC_COLLATE/LC_CTYPE) upon creation. Any other database
template might cause errors unless we select compatible encodings
and locale settings.
As the locale setting is system-dependent, we can't just hope
that there will be no compatibility problem, we must explicitly
default to template0. Therefore the change in
276ea817f4 was prone to causing
locale compatibility errors.
Finally, if users have a reason to prefer a different template, they
should select it explicitly with the --db_template config.
Note: existing environments will likely continue to use `template1`
as a default due to presence of older config files.
Complements #25196
Tests from [1] were not passing, due to changes from [2].
This is due to the fact that `$.('.modal-body')` picks 2 elements, instead of 1.
Partial HTML before [2]:
```
<main class="modal-body">
<div>
<p>
...
</p>
</div>
</main>
```
Partial HTML after [1]:
```
<main class="modal-body">
<main role="alert" class="modal-body">
<p>
...
</p>
</main>
</main>
```
In order to not pick both DOM elements, we refine the jQuery selector to pick
the `<p>`, so that there's only one element and it has the same text content.
[1] [FIX] mail: warn user on record reload before post message
https://github.com/odoo/odoo/commit/b74d1e90ef32893bfbcf750cdf4586c453790b01
[2] [IMP] Improve compatibility with screen readers (accessibility) (#24574)
https://github.com/odoo/odoo/commit/9de1bc0eef6f5bfaa2a8d745431caa361ae91548
This makes sorting and indexing independent of the cluster/machine
configuration, and allows simple b-tree indexes to be used for
prefix-searches on VARCHAR columns without needing special operator
classes (and therefore without needing duplicate indexes).
The 'C' collation is built-in and always available on any postgresql
installation. It also allows any encoding/locale to be used, contrary to
other LC_COLLATE values, so it should never conflict with custom db
templates.
Admins who want to apply a special collation can still do so by creating
the database manually, instead of letting the system do it.
Closes#25196
Revision on https://github.com/odoo/odoo/commit/299ebb2cdf63de2e3967da0d2f3e7effd239812b
[IMP] mail: add moderation on channels
The commit above adds moderated channel. When a message is pending moderation,
it is not yet linked to the channel server-side, which is why there is a hack
to set `channel_ids` on the client side so that the message is visible on the
corresponding channel (only for author of message and moderator of channel).
It is only when the message is accepted that this message is linked to the
correct `channel_ids`. The server provides the updated list of channels that
this message is linked to, but it misses static channels that only make sense
on the client-side, such as "Inbox" or "Starred".
This commit solves the issue by only extending the list of channel registered
on the message when it is accepted, so that static channels are not unlinked
from the message.
Note that it is necessary to update `channel_ids` of the message,
because there could be "relay" channels. In other words, when the moderated
message is accepted, there could be more channels that contain this message.
This fixes the following bug:
Creating an Invoice, clicking on Validate (with no invoice line), and then trying to add a product.
Before this fix, this would throw an error message.
Now it works.
The sequence had a static default value, but when there is an handle, it's important that new items are added at the top or the bottom of the list.
This is a rare case where the defaul_get from the server will be ignored by the view for a certain field.
This will work:
- both in editable mode (inline) and in dialog mode,
- both for X2Many and standalone list.
The scenario is:
- create a new parent model, which has a one2many
- add at least 2 one2many lines which have:
- a handle field
- a many2one, which is not required, and we will leave it empty
- reorder the lines with the handle
This will call a resequence, which calls a name_get.
With the bug that would throw an error at the RPC, but this commit fixes it.
The $as_all variable was mentioned in the doc but it is non-existing in the Python code.
This commit makes clear it is only available on JS QWeb.
Also rename OpenERP to Odoo.
Extension of commit c4f5b9f751
Instead of disabling only the button on which the user has clicked, we
disable all 'Add to Cart' buttons until the end of the transaction.
Closes#24853
opw-1858080
Backport following opw-1851612
[FIX] google_calendar: do not create an event with an invalid id
The id is useful to update existing events but sometimes we are getting some
ids that are not accepted by Google
Getting an error:
odoo.addons.google_account.models.google_service: Bad google request : {
"error": {
"errors": [
{
"domain": "global",
"reason": "invalid",
"message": "Invalid resource id value."
}
],
"code": 400,
"message": "Invalid resource id value."
}
}
Looks like existing events can have a _ in their id but new one, no longer.
It seems that these events are created by outlook calendar when synchronized
with Google Calendar.
On an optimization done for not rendering each time the template, the possibility
of sending the template in the proper language when multiple recipients was lost.
This is being refactoring in master, but for this version, Odoo won't merge a
change in the behavior, although it's the correct one as in previous versions.
Extracted by pedrobaeza from https://gist.github.com/nim-odoo/8a9749037370343f05c7e6681324f576
(cherry picked from commit 386a936)
Commit a3c9c286cc made stripe.js more generic. By doing so it also fixed the
`provider_form.innerHTML = data` that was not doing anything since
provider_form was not a dom element.
For orders on /my/orders/XX, the `return_url` was /my/orders/XX before going
through stripe.js.
stripe.js would then call `/pay/sale/XX/form_tx/` that would return new
acquirer form values that should replace the old ones, including a new
`return_url`.
But since `provider_form.innerHTML` was undefined, the old data would remains.
With commit a3c9c286cc the data is now correctly replacing the old ones.
The `return_url` is now /my.
So when an user pays a SO, he is redirected to the portal root page instead of
the SO he just paid with a confirmation message (like it was the case before
the stripe.js improvement).
This fix ensure that the user is still redirect to his SO, by redirecting to
/my/orders/xxx and not /my.
res.currency's `_convert` expects a record not an id.
On res.currency:
_convert() calls
_get_conversion_rate() which calls
_get_rates()
_get_rates does company.id.
Both features already existed but it was not possible to enable both.
This makes that possible. When both are enabled the quotation first has to be
signed, then it can be paid.
Purpose
=======
No way to combine digital signature and online payments to confirm orders.
A customer signature matters for big deals, in order to keep an official print
of customer agreement.
Specs
=====
- when the customer signs online, a new pdf is generated with the customer
signature on it and posted as a note in the chatter, replacing the current
signature jpg.
- show the signature in the portal view, with both sale_management and
website_quote module
- change in settings: Digital Signature and Electronic Payment are now 2
checkboxes instead of a radio button
- these settings must be company-specific (add company icon if multi-companies,
like other company-specific settings)
- when both modes are activated, it first request the signature, then the
payment
- the order is confirmed after payment
opw-1818837
Closes#24174
The funny self.$('#o_portal_sign_accept') line was some leftover
debugging code. It doesn't actually match anything, because that
element is not in self.$el.
Before this change nothing happened when you clicked the button and an
error occured.
Now the `data.error` message (e.g. 'Invalid Order') is shown near the
bottom of the dialog.
When updating the reservation of an partially available or available
move line, use the current record of the loop and not the whole
recordset.
Closes#25445
The CSS of reconciliation highly uses `overflow: hidden` to hide
elements, but this cut the bottom part of the "Select a Batch Deposit"
list of deposits.
There is no possible overflow in this situation anyway, since in the
given circumstances the `max-height` is set to none.
opw-1859408
closes#25524
In some undertermined circumstances, a `KeyError` might appear in:
https://github.com/odoo/odoo/blob/f9737d79e77e9abf634c8eaa4b6ea331e2aa814d/odoo/models.py#L4898-L4904
Despite the lack of reproducible use case, it seems that this was
introduced from 59b010ac36. In the meantime, other
optimizations were introduced in the prefetching of related fields, and
it seems that the fix is not necessary anymore.
Running the same script than described in
https://github.com/odoo/odoo/issues/19536#issuecomment-333118947 , we
observe the following performances:
Before the fix:
```
On change with 10 lines (10 new, 0 existing) took 0.306
On change with 20 lines (10 new, 10 existing) took 0.221
On change with 30 lines (10 new, 20 existing) took 0.208
On change with 40 lines (10 new, 30 existing) took 0.271
On change with 50 lines (10 new, 40 existing) took 0.306
On change with 60 lines (10 new, 50 existing) took 0.319
On change with 70 lines (10 new, 60 existing) took 0.354
On change with 80 lines (10 new, 70 existing) took 0.382
On change with 90 lines (10 new, 80 existing) took 0.506
On change with 100 lines (10 new, 90 existing) took 0.503
```
After the fix:
```
On change with 10 lines (10 new, 0 existing) took 0.238
On change with 20 lines (10 new, 10 existing) took 0.259
On change with 30 lines (10 new, 20 existing) took 0.250
On change with 40 lines (10 new, 30 existing) took 0.233
On change with 50 lines (10 new, 40 existing) took 0.287
On change with 60 lines (10 new, 50 existing) took 0.325
On change with 70 lines (10 new, 60 existing) took 0.345
On change with 80 lines (10 new, 70 existing) took 0.451
On change with 90 lines (10 new, 80 existing) took 0.496
On change with 100 lines (10 new, 90 existing) took 0.423
```
The fix doesn't seem to be necessary anymore, so we go back to the
previous implementation of the computed field.
Closes#25448Fixes#19536
opw-1861468
Goffin Simon