The field 'Type' should always be readonly since:
- it must not be changed for standard models
- its value must be 'Custom Object' for a custom model
opw-706130
The GeoIP resolver keeps a permanent open file descriptor on the
GeoIP database file, for example /usr/share/GeoIP/GeoIPCity.dat
Because we initialize a resolver for each registry, servers with
many databases may easily blow up the open file descriptor limit
of multi-threaded workers (gevent or no workers multithread mode).
The Maxmind GeoIP API appears to be thread-safe since v1.1.4, so
it is much less wasteful to use a shared resolver for each process.
This patch keeps the _geoip_resolver class attribute on `ir.http`
for compatibility, but it will be removed for the next version.
A couple of places in the processing of bounces only
accepted a single matching partner. But there could
be multiple partners matching an email address, and
we should handle them all.
There might also be no matching `bounced_thread_id`
matched by the regex, so we should guard against a
bounced_thread_id == None.
It used to be based on owners, but owners are automatically
followers. Restricting on followers makes the visibility
of equipments and requests consistent with the mail notifications
linked to them.
Avoids issues with "phantom notifications" that appear in the
inbox counter but aren't visible.
- Enable lot tracking on Product A
- UoM of Product A is kg, but Purchase UoM is lb(s)
- Create a PO for 200 lb(s) of Product A, confirm
- Go in the picking: 200.01 lb(s) shuold be received according to the
pack operation, while 200.00 lb(s) are expected in the stock move.
The field `product_qty` on the sotck move contains the quantity in kg,
but already rounded from the value in lb(s). If we convert it back to
lb(s), there might obviously be a rounding error, since we do:
lb(s) -> kg -> lb(s)
To solve this, we recompute the quantity in the UoM of the product
without rounding, as a temporary computational value.
opw-705259
- Enable lot tracking on Product A
- UoM of Product A is kg, but Purchase UoM is lb(s)
- Create a PO for 200 lb(s) of Product A, confirm
- Go in the picking, specify the lots.
- Validate, and error: 'You have a difference between the quantity...'
This is because `lot_quantities` contains the quantities in kg, while
`operation.product_qty` is in lb(s).
opw-705259
`model` field of `ir.model` may be used as related stored field.
Marking it as modified force recomputation of these, even no change
occurs (by definition).
It is not possible to import Google Drive slides which are not publicly
shared.
Google Drive requires an access authorization from the user, not a
simple API key. The access token is generated in module `google_drive`,
but the latter is not in the dependencies of `website_slides`.
opw-703750
Proxy.load is required by the livechat when it is embedded in an
external page, so that it is able to get the static xml files
(with the correct base_url).
opw-706497
The original issue is the following:
- Configure the warehouse in Pick + Ship
- Activate the packs
- Create a SO with a product which is a consumable
- In the picking from stock to out, add the product in a package, and
validate.
- In the picking from out to customer, the previously created package is
not accessible/propagated as it would be with a stockable product.
The core of the issue is that there are no quants reserved for a move
linked to a consumable product. Since the package information is stored
on the quant, the package cannot be propagated correctly.
The fix is therefore to add the quants reservation feature on consumable
products, but only if the move is propagated from another one (i.e. the
move has ancestors).
That solved our issue, but also makes the workflow more logical. Without
the fix, all pickings are "Available" when created, even though one is
linked to another.
opw-702632
Complements the patch in 8235f03f56
in order to properly bootstrap a writeable data_dir when it is
(partially) nonexistant.
Depending on the startup parameters the data_dir might otherwise
have ended up read-only, preventing the creation of its necessary
components (session store, file store). Only the `addons` directory
of the data_dir needs to be read-only by default.
Before, when you would put a quantity in a BoM line that was not rounded
to its UoM (e.g. use 0.3 piece with rounding 1.0) it would not round this
quantity in the MO also (when exploding the BoM), and the user could also
enter a not rounded quantity himself for the quantity produced or
consumed.
The moves were split with the exact quantities, but the moves were validated
taking into account rounded quantities. This resulted in either moving 2
pieces instead of 1 (entering 0.7 or 1 piece) or raising an error telling
you can not process moves with 0 quantity (0.3 piece).
As product_efficiency and product_rounding was removed from the BoM/BoM
line in v10, if the rounding is correctly handled, the feature could work
like in v9, by e.g. putting 1.03 in the bom line (97% efficiency) and
rounding up when exploding the BoM (e.g. producing 10 pieces would put
it to 11).
When "producing", we round the produced qty to the product uom (it does
not make sense to produce 1.32 if your uom rounding is 1.0). The user
might now change the produced quantity, that's why we round-up when
validating the move: indeed, if the user slightly increase the produced
value (below the uom unit), it actually means he produced more.
This way, instead of not rounding anything and doing rounding behind the
scenes, leading to errors, we round everything and the user sees the
result directly.
The `reference` field is used as `invoiceNumber` in the Authorize.net
API. However, this field is limited to 20 characters. Larger references
will produce an error when the API is called.
Source: https://api.authorize.net/xml/v1/schema/AnetApiSchema.xsd
opw-704615
Modern browser implement the autofill specs as described at
https://html.spec.whatwg.org/multipage/forms.html#autofill
This means that there is now a way to tell the browser when a password
field is supposed to be filled with the user's own password (e.g. on a
login field), and when it's supposed to be used to input a new secret
value (e.g. when changing someone else's password).
This can be distinguished by setting the autocomplete attribute
to `current-password` or `new-password`.
In addition, many browsers have decided to entirely disregard the
autocomplete='off' attribute value, because it is felt that using
a secure password manager (as provided by those browsers) is a net
gain for security, allowing users to pick stron passwords.
See also https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion
Based on this, the framework should generally consider that
password fields in the backend are meant to be used for *setting*
new values (autocomplete="new-password", i.e. no autocompletion!),
whereas the password field on the login page can indeed be autofilled
with the user's current password (autocomplete="current-password").
In addition to making the above changes, this patch also
lets developer specify their own `autocomplete` attribute on
text input fields.
Rev 0ff26cf7cd disabled this option
because it was causing JS errors, which is not the case anymore.
We now get the expected result:
- if product has no variants, open quick add modal dialog
- if the product has variants, open the product page to let
the user choose a variant
Also fix the bootstrap modal bug that happens when the quick add
modal is opened on a product that is not published (modal appeared
partially transparent and unusable)
Some printers (e.g. matrix/impact printers) may have a hard time
keeping up with the text output, and may trigger timeout errors
because of this, even though they would otherwise produce a correct
result.
Increasing the default timeout to 5s (from the default 1s) should
take care of most slow printers out there.
As discussed on issue #15225, it should be possible for system administrators
to disable the 1-click installation system.
The plan is to disable the feature by default, but make it relatively easy
to turn on when it is explicitly desired.
1. At the moment we cannot guarantee that all Apps published on the Odoo Apps
Store are safe. And it is a security risk to let end-users deploy Python
code on their Odoo servers without requiring any review/deployment by a
competent system administrator.
We will work on improving the validation process of the Store, but this
will require time, and won't probably be a 100% safe process in any case.
2. The one-click install feature is however really useful to help
non-technical users install Apps, as long as the feature has been
explicitly allowed by the system administrator. This is a common feature
in other software suites as well. So we'd like to keep it as an opt-in
feature.
3. Administrators of multi-tenant servers, cloud hosting services, etc.
understandably expect to be able to turn off the feature for
security/control reasons.
4. By turning off the feature by default, but still exposing it in the UI,
we keep it *discoverable* for users. The error message should be
helpful to direct users to their sysadmins.
5. By using the permissions of the download folder as a flag for turning
off the feature, we avoid introducing an extra server parameter.
The folder is still created (read-only) by default, for the sole purpose
of making it easier to locate.
Fixes#15225
As discussed on issue #15225, it should be possible for system administrators
to disable the 1-click installation system.
The plan is to disable the feature by default, but make it relatively easy
to turn on when it is explicitly desired.
1. At the moment we cannot guarantee that all Apps published on the Odoo Apps
Store are safe. And it is a security risk to let end-users deploy Python
code on their Odoo servers without requiring any review/deployment by a
competent system administrator.
We will work on improving the validation process of the Store, but this
will require time, and won't probably be a 100% safe process in any case.
2. The one-click install feature is however really useful to help
non-technical users install Apps, as long as the feature has been
explicitly allowed by the system administrator. This is a common feature
in other software suites as well. So we'd like to keep it as an opt-in
feature.
3. Administrators of multi-tenant servers, cloud hosting services, etc.
understandably expect to be able to turn off the feature for
security/control reasons.
4. By turning off the feature by default, but still exposing it in the UI,
we keep it *discoverable* for users. The error message should be
helpful to direct users to their sysadmins.
5. By using the permissions of the download folder as a flag for turning
off the feature, we avoid introducing an extra server parameter.
The folder is still created (read-only) by default, for the sole purpose
of making it easier to locate.
Fixes#15225
As discussed on issue #15225, it should be possible for system administrators
to disable the 1-click installation system.
The plan is to disable the feature by default, but make it relatively easy
to turn on when it is explicitly desired.
1. At the moment we cannot guarantee that all Apps published on the Odoo Apps
Store are safe. And it is a security risk to let end-users deploy Python
code on their Odoo servers without requiring any review/deployment by a
competent system administrator.
We will work on improving the validation process of the Store, but this
will require time, and won't probably be a 100% safe process in any case.
2. The one-click install feature is however really useful to help
non-technical users install Apps, as long as the feature has been
explicitly allowed by the system administrator. This is a common feature
in other software suites as well. So we'd like to keep it as an opt-in
feature.
3. Administrators of multi-tenant servers, cloud hosting services, etc.
understandably expect to be able to turn off the feature for
security/control reasons.
4. By turning off the feature by default, but still exposing it in the UI,
we keep it *discoverable* for users. The error message should be
helpful to direct users to their sysadmins.
5. By using the permissions of the download folder as a flag for turning
off the feature, we avoid introducing an extra server parameter.
The folder is still created (read-only) by default, for the sole purpose
of making it easier to locate.
Fixes#15225
Before this commit, a user that is logged in with a partner of type contact,
was inheriting the address from the parent and didn't have the right to edit
the billing address... stopping the checkout in the middle.
With this commit, we change type of contact if needed to allow the user to
finish the checkout.
ps: Use of write instead of update to make the update in one step, else the
values updated before the field 'type' are ignored because the field is resync
from parent automatically.
This commit is related to: opw-705974 and opw-704653
In some instances we could get a traceback in the form view of an
account.invoice.line object. This is because the `parent` field can be
undefined depending of the way the form view was opened.
For example there can be a account.invoice.line list in a
sale.order.line form and this lead to a product_id with a traceback
capable context.
There are some problems in the way the picking compute its state
according to its move lives if the delivery strategy is partial.
When a picking was in a partially available state and then you would
force availability, the state would stay in partial availability.
Therefore, we changed the way the state is calculated more like it was done before.
This issue stems from the new API migration.
The bank account didn't appear when selecting SEPA credit transfer in ACCOUNTING>PURCHASE>PAYMENTS
to refund an employee. The bank account is taken from partner set with the field home_address_id.
So the account holder have to be set on the bank_account_id of the employee with the home_address_id.
opw:702881
The reverse field of a one2many could be originating from an
inherits'd field, this was solved in some instance with f5e5bbda.
The issue could still happen in some instances when doing a comparison
of:
- the one2many field to a False value,
- the one2many with a negative operator and an empty set to negate,
With this change, the ORM is used in such a situation.
closes#15234
opw-704962
The display label (e.g. "Legal leaves (5 remaining out of 20)") was not
translatable.
Add the 'remaining out of' as translatable.
Replaces and closes#15212
The payment reference of a S2S transaction has the given format:
'PAYMENT-9-170110_200204'. However, the reference is too long for some
providers such as Authorize (limited to 20 characters).
We make the reference less verbose as a first step to solve the issue.
However, case-by-case solutions will need to be found since the
reference depends on the id, which will ultimately grow.
opw-704615
Nicolas Martinelli