This is a followup of 1d553eea7b.
Systematically logging import tracebacks can fill up log files, and
waste disk space. We therefore log those tracebacks in DEBUG mode, so
that they can be activated only when needed.
closesodoo/odoo#45075
X-original-commit: 017e3d798c55b1bdac221aea76d3d944f045ee65
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
* Code cleanup
* Avoid a safe evaluation of the field value when loading those records.
closesodoo/odoo#44883
Related: odoo/enterprise#8283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- Activate variants and pricelists
- Go to Product > Products Variants
- Search for anything on the 'Pricelist' filter
A traceback is raised: 'Can only create cache keys from hashable
values...'.
This comes from the following change:
https://github.com/odoo/odoo/blob/4b06fe19fa68255b7982d15e5847da2f6d6209fd/addons/web/static/src/js/views/control_panel/control_panel_model.js#L962
It returns a list instead of a string. Since a list is not hashable, it
causes the issue.
There are not much solutions since the context key `pricelist` can be a
`list` or an `int` (an ID). We force the cache key conversion to a tuple
to avoid the `TypeError` and handle the `list` use case (which was
broken on top of crashing).
opw-2187757
closesodoo/odoo#45064
X-original-commit: ec0a8767143b4c4818418281803c4f52fefa8d2a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When adding a custom field, the ORM also adds it to all the inherits'ed
models, but with the state `base`, because those inherited fields are
automatic (created by the ORM). However, dependencies are enforced for
`base` fields, while they can be ignored for `manual` ones. This is a
problem when a custom field is fucked up: its inherited fields will make
the registry crash.
We fix the issue by not enforcing dependency check on fields inherits'ed
from custom fields.
opw-2191114
closesodoo/odoo#45024
X-original-commit: 2db0787dc9e8717200aaf1d71ac64df1c17f4143
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When reading binary content such as `image_128` on `res.users`,
`AccessError` should be raised when necessary.
Steps to reproduce:
- Populate cache in superuser mode.
- Access cached field with public user.
- Read access is allowed but should not.
Concrete example:
- Unpublish `demo` user.
- Access `/slides` with `public` user.
- The template data is generated as `sudo`.
- The same data is then accessed as `public`.
- AccessError should be raised when requesting
`/profile/avatar/<int:user_id>` but is not.
Closes#43826closesodoo/odoo#45033
X-original-commit: e0112db4d6131751475365ab4c42de848f925dce
Signed-off-by: Christophe Simonis <chs@odoo.com>
When you have su == True in your env and you call _name_search
the _name_search was switching back to su = False
when you call with_user with the same user or with None
To reproduce the issue, take a model where a user has
no access.control.list allowing to read the model
call name_search with sudo.
X-original-commit: 8755269f9877e039663adaec8500b530b6d67c68
Have a company with Croatian address but no street2 set.
Create and invoice, print it. On the report the street2 will appear
blank (Empty line).
Correcting the formatting of the address fix the issue
opw-2182621
closesodoo/odoo#44789
X-original-commit: 5f4cc31a3b5a459f4a33c149fafb635a13f08270
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose
======
Our current integration between FSM and Stock works well for basic flows, but quickly shows limitations. We don't handle warehouse by employee. Use-case: each worker has a dedicated van with a dedicated stock. I want to track the material used for each intervention to make sure that nothing is stolen.
+ This is also useful in usecases outside of FSM. Example: I have 3 shops (= 3 warehouses), each employee works in a different shop, the default warehouse set on the Sales Order should be the default warehouse of the salesperson. So this should be done sale_stock (and not in FSM)
Specifications
===========
Add a 'Default Warehouse' field on the user only visible if :
- sale_stock is installed
- the 'multi-warehouses' feature is enabled
- domain should only include warehouses which belong to a company the user has access to
- not required
The field should be editable by a user on his own profile and by the admin on all users.
When creating a FSM task from scratch, adding some products creates a SO, the warehouse on the SO should be the default warehouse of the user set on the FSM task.
On SO creation, set the 'default warehouse' selected on the user assigned to the SO. If there isn't any 'default warehouse' set on the user, fallback on the current behavior (warehouse with
lowest sequence)
The field on the res.user should be a property field to allow multicompany usage.
Task : 2166382
closesodoo/odoo#44257
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In 0.15 accessing werkzeug.urls functions directly through werkzeug
is deprecated, the shortcut will be removed in the eventual werkzeug
1.0.
Fix existing uses of these shortcuts. Also cleanup some imports when
they're not far from a werkzeug* import being altered.
assertDictContainsSubset has been deprecated since 3.2 and is not
documented anymore, apparently because the order of its parameters is
less than obvious.
Consequently, remove the call to said dict & replace it with
assertions on item sets.
Note: the odd formatting is because these bits are literal-include-ed
in the documentation as sub-slices (just the relevant code lines), so
ideally they shouldn't be moved around and no additional content
should be added to those specific lines.
Before this commit, models with the `_transient` flag were ignored in
ir.model.access verifications. Only an implicit ir.rule with the
domain (create_uid=user.id) was applied to avoid most side effects.
The problem is that, often, the security does not lie in side-effects
of abusing of somebody else's wizard record but in the fact that the
wizard methods blindly trust only the right users are creating these
records. Too often, too many sudo were used and creating wizard with
chosen values could lead to an abuse scenario.
Instead, explicitly require the developer to declare security rules
the same way as on any other model.
closesodoo/odoo#43306
Task-id: 1863044
Pad: https://pad.odoo.com/p/r.c1befa51103ed3b955a427971eb19719
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
As neither fields_view_get, nor default_get actually verify you have
access to a specific model (this is likely to be changed in the
future), it was possible to execute an action to a model, even if the
user does not have access to the corresponding model.
Before this commit, launching an action to a wizard with no access was
opening a new record view with all fields in readonly and clicking on
any button raised an access error.
To avoid the frustrating of seeing an action but getting an unusable
screen when clicking on it, just hide the action in the first place.
Before this commit models with the `_transient` flag were ignored in
ir.model.access verifications. Only an implicit ir.rule with the
domain (create_uid=user.id) was applied to avoid most side effects.
The problem is that, often, the security does not lie in side-effects
of abusing of somebody else's wizard record but in the fact that the
wizard methods blindly trust only the right users are creating these
records. Too often, too many sudo were used and creating wizard with
chosen values could lead to an abuse scenario.
Instead, explicitly require the developer to declare security rules
the same way as on any other model.
Since this option is soon to be used, this rename is a last tweek
to make it more logical to use since it will point to a single
upgrade dir most of the time.
closesodoo/odoo#44593
X-original-commit: 1c8e2809fb296abce6114b7da906d48a240df418
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Copying a custom model's record seems pointless by default, since
no field is actually copied.
It makes sense to copy at least the `x_name` field, to make it clear
to the user that the system understood it was duplicating something
and not just creating something entirely new.
The fact that there is a company id set means that you cannot select the
partner in a M2o if you didn't select the company in the selector, and
that you cannot open a document where that partner is set if you are not
in the correct company.
This is an issue for inter_company_rules, as you should be able to
select the company to make a so, po or invoice to a company of the same
database.
If an automated action raises an exception, in the traceback modal:
- For admins, display Disable & Edit automated action buttons
to be able to directly know with wihch automated action the error occurred,
and to give the possibility to edit or disable it quickly,
- For regular users, just add a paragraph to tell with which automated action the error occurred,
so they can give this useful information to their administrator
This is specially useful for databases which have just been
upgraded to a newer version, and for which the server action
is failing because its code is no longer supported.
closesodoo/odoo#44513
X-original-commit: 8f3940c132bbbc99e47fa3f0cba0e768159d9af2
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
time.clock is deprecated since python 3.3 and no longer exists in python 3.8
time.process_time was introduced in python 3.3
Replace "is" by "==" as this produces a SyntaxWarning in python 3.8
Fixesodoo/odoo#41313closesodoo/odoo#44502
X-original-commit: f03b4cb5576f264b6845242ba112f02422af4f5f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Closes#43580Fixes#9449
Adds field type conditions for boolean in search for Property model.
As False values are not stored in DB for boolean, the search() does
not return any value for non existent lines with:
* operator: '=' and value: False
* operator: '!=' and value: True
Uses the 'include_zero' and inverse operator mechanisms implemented
in Property model.
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Allow a naive `group_expand` for manual fields where having the
attribute set to True causes the ORM to include all records from the
relation model of the m2o field in the read_group.
This is particularly useful for custom m2o fields which represent
stages - a grouped list view or a kanban view should include all
possible stage, not only the currently used values.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
Up until now, it was impossible to specify the default ordering
on models created manually.
This could somewhat be bypassed by specifying the ordering of records on
views themselves, but this has one main drawback: when using a
relational field that targets a custom model as a group-by key, the
ordering defaulted to the id of the custom record. For example, if I
create a custom field on partners that points to a custom model
'x_grade' on which an 'x_sequence' field exists, I could order my grade
in their own list view according to their sequence, but any read on
partners grouped by this 'x_grade_id' field would order the returned
groups by id while I would prefer to have them ordered according to the
'x_sequence' field.
This commit introduces a new field 'default_order' on the ir.model model
that can store this default ordering clause (as an SQL expression).
Co-Authored-By: Raphaël Collet <rco@odoo.com>
In some cases, the registry might be updated during a test step
(creating custom models/fields, for example). In those cases, there
should be an explicit call to `reset_changes` on the registry to make
sure that the next test class starts with a registry that is consistent
with the database state.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
When removing a custom model, it remained listed in the base classes
(normally `base` and also possibly a list of mixins; e.g. `mail.thread`
or `mail.activity.mixin`) list of inheriting classes, possibly causing a
crash when trying to reload the registry.
This commit ensures that any custom model is removed from its parent
class `_inherit_children` set; it will be re-added automatically during
the call to `_build_model` if the custom model still exists.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
When the db reflects the python models at startup, a query is generated
to update various `ir` models (models, fields, etc.). This query did not
properly escape identifiers, preventing the use of the 'order' field
name on ir.model because it is a reserved keyword in SQL and wasn't
escaped.
This commit introduces proper escaping for these reflection queries.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
When revamping the message fetching from the headless browser, since
stacktraces are available (by default) on console.error and
console.warning events I assumed it could / would be useful to show
them in the Python-level log. And they *were* quite useful during the
original fixing stage.
However they turn out not to be very useful day-to-day:
* they add a lot of noise and lead to the error message itself being
lost in a big block of red / logging.error
* when a tour fails (which is the vast majority of the failures) the
JS stacktrace always points to the same location in the tour
manager (the one which goes "this step never succeeded") which is
completely useless
* aside from being bundled, normal JS code (where the stacktrace could
be useful) doesn't generally use console.warn or console.error, it's
going to straight blow up with an exception in which case we always
get a stacktrace
Leave the stacktrace formatting for console.trace as that's pretty
much the only point of using this instead of console.log.
closesodoo/odoo#44343
X-original-commit: 34500853f39c9557852cb83cbc274f59d803922f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
With this commit, the url widget automatically prefixes the href
url by http:// if no protocol is specified, so that clicking on
the url will by default redirect to an external website.
To prevent this behavior, one can still specify the new option
'website_path: true' on the url field node in the view arch.
Thanks to this, we can remove a similar logic (only implemented on
res_partner model) which automatically altered the value saved in
database to force its 'http://' prefix.
task-2153184
closesodoo/odoo#42118
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The issue is: the user wants to send an invoice to a customer, changes
the email template, and after the onchange, the field "Template" of the
wizard is empty.
Here is what happens. The onchange on the template renders a PDF file
with the corresponding invoice document. The rendering builds some
assets to convert the invoice to a PDF document, and former assets are
deleted. The deletion of former assets (`ir.attachment` records)
invalidates the whole record cache, which implicitly clears all the
fields of the record of the onchange.
The problem is that the asset is systematically invalidated by the
rendering of the report itself. This hack changes the CSS assets to
introduce company-specific colors for the rendering of reports. This
implementation is actually not consistent with the fact that assets are
kept in cache by the server.
This patch does not fix the root cause of the problem, but it reduces
the sides effects of it, and makes the issue above less frequent. It
simply consists in not updating the asset's attachment when its value is
already correct.
OPW 2168623
OPW 2171040
closesodoo/odoo#44295
X-original-commit: b1ddd9c95bc642e42eb0d3d51066902d5283ba04
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
* remove misleading documentation about a "test failed" message, in
13.0 any uncaught exception or console.error will cause the current
test to be interpreted as failed
* fix tour manager to console.error its step and not add a second
useless error message
* fix menu tester to try and display the failure cause on failure
* improve qunit's test reporter to print the number of tests failed in
case of test suite failure
Should make test failures in tours a bit clearer.
closesodoo/odoo#44296
X-original-commit: 78121b68d099b16f2d775a7a8a963a2a0f474843
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In this commit, we add a new attribute "Delete" for user conveniency
if he don't want 'Delete' button on popover card they easily achive
by "delete=false" attribute and also add a testcase for it.
task-id:2088954
When we name_search a res.user, we have a special hack so we will
firstly perform an exact search on the res.users login, if none is found
we will search over res.users name.
This is intended but in the case of negative search since 660cebb4faaeb,
for example operator='not ilike' and name='test' would probably just
return all user that do not have a login that is exactly test.
This is not the intended behavior, in this instance we should just
return user that do not have "test" in their names.
Without fix, added test would fail on:
- .name_search('vlad', operator='not ilike') => finding everyone but
user with exactly login vlad instead of user not containing vlad in
their name
- .name_search('', operator='not ilike') => find all users instead of
finding no user
- .name_search('lad', operator='not ilike') => find all users instead of
just finding "Nothing similar"
opw-2170517
closes#44040closesodoo/odoo#44152
X-original-commit: 2378fb63c132c0bcf027785d478c0608b59a3409
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Migration have long been only accessible thanks to a symlink from
`odoo.base.maintenance` to our private migration repository. Thank to
the change of bbb1a8f it is now possible to give a load the
migrations scripts from a path given in options.
The `initialize_sys_path` function has been updated to hooks the new
paths or the legacy symlink and to provide aliases to the previous
import logic to ensure backward compatibility.
`odoo.upgrades` (`community/odoo/upgrades`) is a new namespace that hook
all `--upgrades-paths` directories or the
`community/odoo/base/maintenance/migrations` symlink if none is previded.
`odoo.addons.base.maintenance.migrations` has been made an alias to
`odoo.upgrades`.
The `odoo.upgrades` is the desired method for accessing migrations
scripts and should be used by all new scripts.
closesodoo/odoo#44117
Task: 2178274
X-original-commit: d963cc05acd882729c4eb5ab940dae2a2197e55a
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When simply need to parse a domain, it is easier
Add .strip() on ir.ui.view as ast.literal_eval produces an syntax
error if the node starts with spaces (as done in the xpath of
hr_attendance.view_employee_form_inherit_hr_attendance)
closesodoo/odoo#43831
Related: odoo/enterprise#7894
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Victor Feyens