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
A few month ago, based on unclear specs, something was merged.
Today, we come back, since it does not do what we want. We do
not take into account the fact that between 2 printings, the user
has changed its report layout or its data company.
Initial commit : dccfdb0ddb
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
Purpose:
emails: button setup your domain alias has an odd bahavior: redirecting to base.config.settings. Like in "generally speaking", I feel like some kind of highlighting the field to set up would be nice, or reproduce the setting item in CRM, or open a wizard
On kanban records in the sales dashboard:
the display got modified and links on the right side were taking 2 lines
instead of 1, Going to a new line after the number.
display: "block" needed to be "inline-block" -> added to sales_team less file.
In the loop `for action in self`, if all iterations
passed in the first `if` block only, res
was never assigned, but returned.
This is an oversight during the conversion of the module to the new API
in revision eb04aa1e39
One could ask himself why `res = False` is before the loop
and not in this `if` block, but we believe this is
in the case multiple actions are passed to this method,
you wouldn't like the result of the first actions in the loop
to be overwritten by `False` when the condition of the last
action of the loop is not met.
For instance the first action returns as result an action but for the
second, the condition to run it is not met, in such a case
you would like what the first action returned as action.
opw-706150
The test wizard will be dropped eventually but it is not possible to delete
the mass-mailing before the transient is cleaned too due to the required field.
To make it faster, add a ondelete cascade on the field.
Closes#15217
Simone Orsi