Complements the patch in 4715d18e12
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.
When validating a new order in between the create_from_ui RPC call and
the corresponding callback this new order was lost. There were two
reasons for this.
First of all, the Mutex supposed to prevent multiple create_from_ui RPC
calls from happening at the same time did not return a Deferred. This is
problematic because this function gets passed to jQuery.when() which
will consider functions that do not return a Deferred to be resolved
upon return.
Secondly, the resolved callback of the create_from_ui RPC call naively
deleted all paid orders, assuming they were all successfully sent to the
backend. This is not the case when an order is added to the orders array
in between the RPC call and the callback.
Closes#15190
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
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.
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 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
Rev. 36f6f26 changed the format of the returned list of employees.
Javascript is expecting an array containing the array of employees,
each employee being a dict with keys id, name, email. But from rev.
36f6f26, it returned an array of employees, themselves represented
by an array containing their id, name and email.
As the format changed, the Javascript mention mechanism never used
the prefetched employees, and always fallbacked on an RPC to fetch
suggestions amongs all partners.
Don't enable evented mode unless gevent is enabled.
Previous code was activating evented mode as soon as gevent is imported which
may happen in different scenario but is not enough to assume the GeventServer
is actually running.
Closes#13463
Since `model` is not a required field, the invalidation may crash when one is
missing.
It should never happen than a mail.message has a res_id but not a model as it
makes no business sence.
However it is possible than a message temporarly misses one of the two, e.g:
```
self.model = False
self.res_id = False
```
will trigger two writes and will crash at the first.
Above code should probably be refactored to have only one write but this commit
fixes a regression introduced at 8f1c2bfc (the above code did not crash).
Closes#15199
template contains the mail template to render and is the result of the call to
`self.env.ref('account.email_template_edi_invoice', False)`
If the template does not exists (deleted), template is `None` and the action
rendering crashes.
While it is not recommended to delete master data, it is still possible to use
custom mail templates.
Closes#15204
The field company_id is not required on the res.partner and is used when the
portal user is created for portal access.
If the partner as no comapny set, the creation crashes (required on the user).
Use system default company, with possibility for overwrite.
Closes#15030
Scrollbar appeared in Firefox (at least 50.1.0 and up). Related to
depending on non-standard behavior when setting height on a table. For a
detailed explanation see f0eeed93dc.
In this case we can simply ignore overflow on the main POS window since
the height difference introduced is only a couple of pixels.
The POS uses tables to do some of it's layout. It also sets 'height:
100%' on a lot of these tables in an attempt to restrict their
height. The CSS standard however defines the height property on a table
as follows:
"A value of 'auto' means that the height is the sum of the row heights
plus any cell spacing or borders. Any other value is treated as a
minimum height." [1]
Chrome and Safari seems to handle this height property in a way that it
does in fact restrict height. The behavior of Firefox and Edge however
is more in line with the spec, and in these browsers table height is not
restricted by this property.
Because of this the contact list was not scrolleable in those
browsers. To resolve this we stop relying on non-standard behavior by
displaying the relevant contact list elements as regular block
elements. Additionally, we now have to recompute the height of the
client list whenever we show/hide the client details, something that
wasn't necessary before.
[1] https://www.w3.org/TR/CSS21/tables.html#height-layoutFixes#11020
The sizes of these UI elements are all fixed and non-responsive and
everything is supposed to fit. Currently however Firefox (at least
50.1.0 up to nightly 53.0a1) is computing the width of a <br> element to
be 0.0166626px, forcing the numpad to wrap to the next line. This forces
the numpad to be 216px wide (width of 4 buttons at 54px each).
These links are links to the Website live chat app description,
not our actual livechat support.
Besides, we currently do not make support through the
livechat.
opw-705614
to avoid postgresql reserved keywords.
fields like fetchmail_server.user or mail_mail.references uses reserves keywords and must be escaped
Closes#15177
This commit has been forward-ported by error in 9 and +.
Update website_sale.js to fix impacted databases.
Decimal precision in v8 = 0.01, and v9+ = 2
With fwd port, int(0.01) instead of int(2) because data-precision
appears 2x, first with 0.01 (v8), secondly with 2 (v9+).
Js fix uses the last decimal-precision (v9) instead of the first (v8)
The "Inventory at Date" has several issues:
- graph and pivot views are not available despite their existence
- the views are not linked to an action, thus it is impossible to save
it on the dashboard.
opw-703649
If the user tries to save on the dashboard a view which was not open
through an existing action, the call to method `add_to_dashboard`
crashes because of incorrect arguments (`action_id` is undefined in JS).
This is for example the case when trying to save an "Inventory at Date"
in the dashboard (will be fixed in a subsequent commit).
opw-703649
Be a little less strict when not showing o2m list view warning so if the
o2m is not editable (a modal is open instead of editing inline) we still
show warnings.
Also have warnings over modal overlays so they can be used for modals.
opw-702333
hendrikw25