a696f84f1f adds a few extra fields to the
Private information tab of the employee form. As a result, HR personnel
and employees could reasonably expect these fields to be protected in
the same manner as the other private fields. Make it so.
Cherry-Pick of odoo/enterprise@533db05b5eFixes#18610
PostgreSQL 10 move sequences' metadata fields into a new `pg_sequence`
system catalog. As a result, selecting from a sequence relation now
only return three fields, and does not include the `increment_by`
metadata field anymore.
This patch obtains the `increment_by` value from the new system catalog
for PostgreSQL server versions >= 10.
Fixes#20269
PostgreSQL 10 move sequences' metadata fields into a new `pg_sequence`
system catalog. As a result, selecting from a sequence relation now
only return three fields, and does not include the `increment_by`
metadata field anymore.
This patch obtains the `increment_by` value from the new system catalog
for PostgreSQL server versions >= 10.
Fixes#20269
PostgreSQL 10 move sequences' metadata fields into a new `pg_sequence`
system catalog. As a result, selecting from a sequence relation now
only return three fields, and does not include the `increment_by`
metadata field anymore.
This patch obtains the `increment_by` value from the new system catalog
for PostgreSQL server versions >= 10.
Fixes#20269
Further improves on previous commit:
- Remove some unnecessary cruft
- Make names/labels more consistent
- Make fields and their ordering more consistent in list views
- Change "active" field on rules into an "Archive" button
- Slightly improve inline doc on rules form view
- Add colors for "global" rules and "apply-for-all" access rights
('Global' is an info, but "Apply For All" is a warning, as it can
indicate an ACL problem)
Python 3 (before 3.6) is affected by outstanding issue 24291:
https://bugs.python.org/issue24291
In Python 3.6 the issue is gone thanks to this patch:
https://bugs.python.org/issue26721
The base StreamRequestHandler class does not properly deal with raw IO
output streams. This affects most HTTP servers that use it, including
werkzeug. It causes large HTTP responses to be truncated when the
output socket is unbuffered and in non-blocking mode.
This is the case in multi-process mode (workers > 0) due to the socket
timeout configured to avoid worker deadlocks.
Typically, large file downloads (2MB+) and large JSON responses will be
truncated and cause corrupted files or errors on the client side.
As a workaround, we turn on the buffering on the output stream by
default in multi-process mode (it is already turned on for the input
stream) when running on Python 3.5.
See also the socket.makefile() method and the docstring of
`socketserver.StreamRequestHandler` at
https://github.com/python/cpython/blob/dcb101e7f078f12fc3d2bf1730410798a880bfe3/Lib/socketserver.py#L707Fixes#20158
opw-777120
There was a leftover explicit conversion to bytestrings during the
parsing of HTML email parts.
This translated into a parse result with `msg_dict['body']` as a `bytes`
instance in Python 3, instead of the expected text type.
Coercing the result of etree.tostring() with UTF-8 encoding to a
native string should preserve the semantics in both Python versions
without this side-effect.
+ simplify another instance of native string use
- simplify unicode handling for Py2 and Py3
- fix Py3-related bugs, such as passing bytes for context['tz'], making
the conversion silently fail, or attempting to decode() a text
- There was no feedback to the user when executing the Charge
transaction in server-to-server mode, while it could take several
seconds, with the normal UI/action buttons still available.
- Stripe integration was almost working along with `website_quote`
payment, but entirely broken with `website_payment`, and partially
broken with `website_sale`.
Fixing it required:
+ More leniency in processing optional transaction parameters, which
may or may not be present in the various payment flows.
+ It also required more precautions when locating the transaction for
which the Stripe Charge was to be created, which passed in different
manners in the session. The route now supports an explicit `tx_id`
to allow forcing the transaction without risk of mixing different
payment flows.
+ FIXME: There is still some amount of duplication and bad modularity
in the handling of the various payment flows in relation with
Stripe.
- We provided very little metadata to the Customer and Charge APIs of
Stripe. We now pass more names and references to make Stripe payments
easier to manage in the Stripe dashboard.
- In some cases, selecting Stripe as payment method caused a second
inclusion of `stripe.js`, raising a JS error because of the
duplication.
- Strip whitespace in emails: the Stripe API raises an error for
transactions done with invalid emails, including with
leading/trailing whitespace.
Customers will have a hard time figuring out the problem
by themselves, so we should at least strip whitespaces.
- The `--no-database-list` option will now also block access to database
management functions and screens.
Presumably this flag should only be used in production when all
databases have been provisioned, so the admin should like to block
access to the db manager at the same time.
- If no `--database` or `-d` parameter is provided, the system will be
unable to fetch a list of databases at all, so users will be blocked
with an error message.
- Hide the link on the login screen to the DB manager when it is
disabled, to prevent sending users to an error page.
- Weak attempt at updating the documentation
Note: the security check for RPC methods could have been done in the RPC
dispatcher, however that would not have protected service methods when
called directly, e.g. by a controller (e.g. the dump method).
- Add support for hashed master passwords (super-admin password) using a
strong scheme (PBKDF2_SHA512).
- Replace the password with a hash in memory (tools.config map), after
verifying it
- Automatically replace the plaintext master password with a hash when
saving it after a password change
- Preserve support for setting/using plaintext passwords when necessary
(e.g. as a temporary deployment thing)
The 'xmlrpc'-based configuration parameters have been a misnomer since
the introduction of the generic HTTP service, years ago.
Hide these options from the server parameters, and replace them with
more appropriate 'http' ones:
--xmlrpc-interface -> --http-interface
--xmlrpc-port -> --http-port
--no-xmlrpc -> --no-http
The config entries for these have been adapted as well.
The old parameter names are still silently supported in both
command-line arguments and config files. However they are
stored with the new names in the `tools.config` dict,
and when saving config files (with the -s option).
Also clarified and cleaned up the descriptions of the HTTP/WEB server
parameters.
And finally, added a short version `-p`, for the `--http-port` option.
Credits to @dreispt for this (via #19518)
Closes#19518Closes#19778
Verifies that admin operations on modules/apps are indeed performed by
an administrator, regardless of ACLs on `ir.module`.
Also logs these important operations, whether completed or blocked.
Coercing the result of the compilation to text is easier and more
portable than P3-specific code for putting the Popen streams in text
mode.
Fixes#19659
This is an attempt at fixing the long timeout occurring on P3 when
trying to stop the server with Ctrl-C, both in multithreaded and
multi-process mode.
The root cause is the implementation of PEP-0475[1] as of Python 3.5,
which make system calls silently resume after an interrupt.
With this PEP, interrupting a syscall now requires the signal handler to
raise an exception, which get propagated in places where they did not
use to occur (e.g. time.sleep() used to return early when interrupted)
The solution handles 2 separate cases:
1. Multithreaded
In multithreaded mode, stopping the server requires interrupting
the main thread, while ensuring that all other threads are daemon ones.
The previous commit fixed the latter.
Interrupting the main thread is easy, because it simply sleeps until
it gets interrupted. And it already catches KeyboardInterrupt for
win32 quirks. All we need to do is thus to raise a KeyboardInterrupt
in the signal handler, as proposed in PEP 475 (Use Case 2)
2. Multi-process
In multi-process mode, stopping the server requires interrupting the
main thread of each process. The signal is already propagated to all
processes, so it should be as simple as for multithreaded mode.
Unfortunately, the main threads are far from idle in this case,
and raising a KeyboardInterrupt from the signal handler causes a
series of ugly tracebacks before stopping the server.
Effective, but frightening for the admin.
Instead of doing that, we can watch the wakeup file descriptor
(also suggested in PEP 475, Use Case 2) during the sleep() part of the
main loop of each worker. An interrupt signal won't therefore stop
the server immediately, but will wait until each worker is done with
their current request.. even better.
For select() syscalls, this is done with an extra pipe fd that is passed in
the "read fds", and used as wakeup fd.
And for sleep() syscalls, that don't support a wakeup fd, we can
replace them with an equivalent select() call on the wakeup fd, and
a timeout.
The combination of the above seems to restore a relatively fast
interrupt shutdown on both Python 2.7 and Python 3.5, in both
multithreaded and multi-process mode, with no surprising traceback.
[1] https://www.python.org/dev/peps/pep-0475/
P3 got rid of all __private attributes in the `threading` module,
via python/cpython@d06489945f.
Our old code for forcing the `daemon` attribute on an already started
thread used the mangled private name and does not work anymore on P3.
We need to use the new private attribute name (actually both,
to keep backwards-compatibility w/ P2)
This might have deserved a pycompat counterpart, but setting both
variants of the attribute works with no hassle. It should not be a very
frequent use case either.
By using the thread's repr() we get its type, name, daemon status and
ID, all at one time. No need to include them separately.
Fall back to the threadId in case the repr() is empty, which can
happen for exotic threads (the gevent main thread seems to be like that)
Introduce a new attachment field (access_token) to allow external
unauthenticated access. This will be an opaque unique number
(typically a UUID) that should be provided via an appropriate
controller, for unauthenticated display.
The field is intended to be NULL unless unauthenticated access has been
allowed, in which case a value will be set for the access_token.
This could be used e.g. for allowing access to images within mailings,
even when the recipient is not logged in (which is sometimes entirely
impossible, when email providers use restricted proxy servers to
load images)
Note 1: this is still a work-in-progress, but serves to freeze the API.
The implementation of the access check and provisioning of the new
field will be added later.
Note 2: namimg collisions with the file download token prevent the use
of a shorter 'token' parameter for download routes.
Apologies for the late (and incomplete) addition in saas-18 :-/
After removing the `sha_in` params a while ago, we get rid of
the deprecated `token_field` option.
- Make `token_field` a model attribute, so that each model can easily
define the token field that should be used, and it does not need
to be passed around all the time anymore.
- Rename `_special_access_object()` to `_has_token_access()`, much more
readable since it returns a bool
- Do not forward the `attachment_ids` keyword arg to message_post,
as it sometimes contains unrelated IDs (the helper is not meant
to post attachments anyway)
- Update callers accordingly
The default size limits set in base.sql are eventually superseded by the
actual limits (or absence of) when the DB schema is synchronized with
the Python model definitions.
However the list of modules (name, authors, descriptions, dependencies)
is loaded before this can happen. The length of the author field is one
case that can easily crash the database bootstrap process at that point,
should a module with a long author name be present in the addons path.
After schema sync, that size limit is lifted entirely (although Odoo Apps
does limit the max author name length to 512 at the moment, to prevent
abuse).
Fixes#5850
Users will generally not have the right to read Journal Items unless
they are members of one of the Accounting/Invoicing groups.
Removing the payment-related fields & widgets from the view should let
those users view relevant customer invoices (e.g. for Salesmen) without
getting an AccessError, due to the underlying access to Journal Items.
As of P3 socket.error is replaced by IOError and the underlying error
code must be accessed with `.errno `. This also worked in P2, so simply
use that all the time.
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
- jcconv is not P3-ready and is only optional, for use on the POSBox
firmware for Japanese charset support in some receipt printers
(The POSBox firmware is still based on Odoo 8 + PY2 at this time)
- wsgiref is built-in since Python 2.5, and the one on pypi does not work
on Python 3.2+
Merge wizard contained dead code with references to an unused lib for
validating emails. Removing everything is easier.
+ remove unnecessary pycompat wrapping for safe use of dict.items()
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
New saas-16 web views have a more consistent handling of `readonly`
attributes and do not save read-only fields inside x2m. In the previous
implementation this was an exception to the rule (even if rather
inconsistent/unexpected).
A new attribute `force_save` was introduced to workaround the default
behavior when considered necessary.
The portal wizard is affected by the change, as the partner_id field of
the lines is readonly but required. It could be avoided by filling the
wizard lines before opening it, instead of relying on default values and
onchanges. However this would likely require extra boilerplate code and
an extra server action. Dropping the readonly flag would work too, but
would look weird.
Using the new `force_save` flag is a simpler alternative.
See also rev. 3b3f6f04af
As of saas-16 and the new web client views, the "display value" for a
record's ID is now formatted with thousand separators.
This breaks a few kanban views where the ID was inserted into a
dynamic URL. Using `raw_value` is correct too and fixes the problem.
Note: This might affect other kanban views using integer field values,
but a quick search did not yield anything. Many2One fields already had
different "display values", so `raw_value` is already used when needed.
Other integer fields, such as computed counts and sums are often
displayed but not inserted into URLs or technical values where
the problem would occur.
Backport of 0de067cae9
(and 9b8bc5e5a1)
Rev. c5bd509274 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
Rev. c5bd509274 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
The new "My Activites" filter introduced by rev. 87e457158e
should not be in the same group of the search view as other activity
filters (Overdue/Today/Upcoming), otherwise they are combined with OR
instead of AND.
This is particularly misleading when coming from the Sales dashboard, as
the "Overdue" button of "My Pipeline" will lead to a list of
opportunities with "My Activities OR Overdue Activities", showing *all*
opps with overdue activities, not just yours.
`parent_id` fields are common in many models, and thus default values
for those fields are sometimes passed in the context.
Because mail.message also has `parent_id` field, it would automatically
use the default when an automatic message was being posted. While of
course, the parent_id value comes from a different model.
This "adoption" by a random "parent message" is unexpected,
not desired, and it can even cause a very surprising AccessError if the
parent message is not readable by the user.
Forcing the `parent_id` value during the creation of an automatic message
avoids this confusion.
One way to trigger the bug was to use the "subtask" stat button to create a
child subtask for a project task (it relies on the parent task ID
passed in the context)
The ETA displayed on a mailing should only switch from the scheduled
date to the next cron run when the cron run is after the scheduled date.
Previously it could jump in the past on the scheduled date, if the next
cron run was in the past (delayed or in progress).
After rev d938ba87ae, taxes that are
included in the price are subtracted in case the tax is not applied in
an order (e.g. when the fiscal position remove the tax).
Some of the test orders did not apply any tax, and because the products
used in the test had some tax included, the above revision made the
tests fail (by subtracting the tax amount from the price).
Fixed by making the test orders more consistent wrt to taxes, applying
the taxes as would happen in the UI, then correcting the payment amounts
to include the extra tax amounts.
Version 2.7.1 is not yet available in most distributions,
but is now considered the recommended version.
Odoo will work just fine with any psycopg2 version >= 2.2, though.
NUL characters must not be used in query parameters,
as they will be ignored by libpq, being end-of-string
characters.
Preventing NULs avoids unexpected results from
queries. It is only necessary with psycopg2
versions before 2.7, which includes the upstream
fix.
NUL characters must not be used in query parameters,
as they will be ignored by libpq, being end-of-string
characters.
Preventing NULs avoids unexpected results from
queries. It is only necessary with psycopg2
versions before 2.7, which includes the upstream
fix.
NUL characters must not be used in query parameters,
as they will be ignored by libpq, being end-of-string
characters.
Preventing NULs avoids unexpected results from
queries. It is only necessary with psycopg2
versions before 2.7, which includes the upstream
fix.
Empty forward-port because commit 21f93b8035
is only a backport that does not need to be forward-ported again.
The point of this fwd-port was to resolve the conflicts immediately.
As a consequence of rev. 76cd8d2558,
imported modules were unable to access their resource files during
import.
Rather than further modifying the file_open API to whitelist paths
(the whole thing needs a redesign in master), we temporarily
whitelist the temporary directory by including it in the global
addons_paths, making sure to undo it afterwards.
This gives all lower level function access the resource files via
file_open, without having to pass around whitelisted paths
through many different calls.
The import_module() method does not need to be public,
so let's mark it private. It's not called by anyone
except import_zipfile().
After 76cd8d2558 it would
fail anyway because addons_path would not be prepared by
import_zipfile().
Olivier Dony