Steps to reproduce the bug:
- Give 'Administrator' rights for the Sales app and no rights for the Point of Sales app to the demo user
- Try to access CRM > Sales > Team Pipelines as Marc Demo
Bug:
Access Rights error on pos.session
opw:2184032
closesodoo/odoo#44637
X-original-commit: 77f0d6280e64074a3188dfb85d688ab758400128
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Task 2146469
Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool
This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.
The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.
The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.
** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002
closesodoo/odoo#41485
Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
*: web
Before this commit, when a widget declared assets to lazy load through
the assetLibs key, the asset was loaded through a context-less call to
the server through the base `rpc` function. This caused problems in
website: the website ID was not given to the called route and the loaded
assets were then stripped of their specific-website parts.
This commit solves the problem by allowing the `loadLibs` and
`loadAsset` functions to receive an extra argument: an extra `context`
to use for the actual call to the server. The method is now available
in the ajax service, so that website can add its custom context
automatically, the same way it does it for normal `_rpc` calls.
Part of https://github.com/odoo/odoo/pull/44596closesodoo/odoo#44596
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: partner_autocomplete
Those cannot be properly lazy loaded by test widgets, so they are loaded
directly through test assets. Testing lazy loading should be part of
a dedicated test system.
Part of https://github.com/odoo/odoo/pull/44596
Follow up on 4f5334a081
Before this commit, thread was not re-rendered correctly in Discuss
App when user clicked on "Mark as Read" from Inbox and then changed
conversation in a narrow time frame.
This issue was discovered from a test that failed undeterministically
on rare occasions (once every hundreds of builds on Runbot):
```
QUnit test failed: "mail > Discuss > all messages in "Inbox" in "History" after marked all as read"
[message: "there should be 30 messages in History", actual: "0", expected: "30"]
```
This test crashed due to the rendering of Inbox after message fadeout
animation that overwrote the rendering of History. As a result,
thread widget indefinitely displays Inbox content, which is empty.
The HTML content of Discuss during the crash shows that breadcrumb
and discuss sidebar correctly have "History" as the active thread,
but thread widget still shows "Inbox" as content:
http://runbot.odoo.com/runbot/build/1092504
This commit fixes the issue by re-rendering of the thread with
message fadeout animation only if the active thread has not changed.
closesodoo/odoo#44585
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Issue
- Install eLearning
- Delete a rating
- Go to the course page, review tab
Only the stars disappeared.
Cause
Review = rating + message, the rating is the stars and
publisher_comment
So this is normal if the review is not completely deleted
Solution
Seen with SBU and he said that the message should be deleted
too.
OPW-2181568
closesodoo/odoo#44529
X-original-commit: 1f41c7ae9de061ec861a3a3db9c403510861cc76
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If accounting entries have already been generated by this currency, we now forbid setting it a lesser number of decimal places (so, higher rounding factor). We also display a warning when increasing the number of decimal places, to make sure the user is aware of the impact it'll have.
closesodoo/odoo#42017
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This commit prevents sending a notification within Odoo when a
message is posted from a mailing channel to a user whose notification
management preference is set to "Handle by Emails".
Task-ID 2033302
closesodoo/odoo#36000
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
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>
- Create a partner which is a company
- Add a contact
- Create an invoice for the contact, post it
Both the contact and the company are set as followers of the invoice.
Only the contact should be, there is no reason to make the company
follower too.
opw-2179084
closesodoo/odoo#44624
X-original-commit: daedd9eb402e5dd3c6a700a93ee58022266ec95b
Signed-off-by: Nicolas Martinelli (nim) <nim@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 you can only reconcile entries from the same partner, you must always use
the commercial partner when creating some journal items.
closesodoo/odoo#44614
X-original-commit: 1ba501d18bc151eb8c5f04fcd23a87d46690010e
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Simple `this` instead of `self` mistake which prevents the widgets to
trigger up events.
closesodoo/odoo#44617
X-original-commit: 033ad6680794e037566720f35b0285e18f3d2130
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When an order is synchronized to the server, there is a timeout of 7.5
seconds that is left before considering that the order has not been
synchronized, and should be re-syncronised.
Since syncronization of order in pos_restaurant have been made, there
are more operations than before that are performed, and the
synchronization of an order can take more than that.
The validation of a picking can also take a lot of time, almost when
products are kits and compose of multiple products.
The problem, is that if it takes more than 7.5, the same order will be
pushed again to the server, even if the previous sychro still running,
which will lead to wait the previous request that has the lok on the
same records, all this blocked request can lead to block all workers of
the server because all requests are trying to modify same objects.
So we've increased the timout for flushed orders.
closesodoo/odoo#44615
X-original-commit: 9452c3f873c86a4c8502695720be942a76d4d25d
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Purpose
=======
Before this commit, the method _mail_find_partner_from_emails could
return a list mixing partner ids and partner recordset, that could
lead to issue when trying to read the different elements.
With this commit, we ensure that we return a list of records only.
closesodoo/odoo#44608
X-original-commit: 2fbbbd8609fd2e08545ddb1ab8e2d7d22ee4d292
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
It very rarely happens that the test is failing due to the following error:
`Tour shop_list_view_b2c failed at step
.oe_product_cart .oe_currency_value:contains("825.00")`
The value found in that case is 750 instead of 825, which indicates that the b2c
setting was not correctly activated.
To exclude the RPC themselves from the equation, it is decided here to move the
setting change directly in the Python.
closesodoo/odoo#44599
X-original-commit: 735807cefb7ccf3232f7492b825ce8c42bacbed4
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
@Julien00859 already made a pass on this at some point but there's a bunch of warnings either dynamic or from not the stdlib left over.
Some of them can't really be fixed in-code and have been explicitly ignored instead:
* `setuptools` uses the deprecated `imp` module until v41.6.0
* `zeep` uses defusedxml.lxml which was never intended to be a public / production API, not sure what to do there (cf mvantellingen/python-zeep#956)
* there are a ton of invalid escapes in non-raw string literals, they're unlikely to ever be relevant so ignore them
closesodoo/odoo#44164
Related: odoo/enterprise#8130
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Replace an assertRaises(StopIteration) by a next() with a default
value.
Following PEP 479, *any* StopIteration reaching the toplevel of a
generator triggers a DeprecationWarning. And while the assertRaises
looks innocuous, both _assertRaises and the underlying
clear_upon_failure are implemented with functools.contextmanager,
which wraps a generator.
As a result, exceptions raised in the assertRaises "body" get
reinjected inside the wrapped context manager[0] and if the exception
is a StopIteration it triggers the warning.
By not using assertRaises we side-step the issue.
[0] https://github.com/python/cpython/blob/b6999e5690c7006b0ba4049cfd638513c982a90c/Lib/contextlib.py#L131
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.
Adding preview of expenses attachment to journal view.
When creating an expense, files can be attached (e.g. scanned receipts).
Those attachment files where not displayed in "Accounting > Accounting > Journals > Purchases" move_line list.
They now appear in the document preview.
Task = 2176443
closesodoo/odoo#44161
Related: odoo/enterprise#8002
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
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>
The creation of a new blog post is noisy.
The user is disturbed with colors (purple box, blue borders, etc).
task-2144335
closesodoo/odoo#43692
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, the covers from event & blog, which shares the same
template, would be set a fixed bg-primary color which couldn't be
changed.
This commit adds the possibility to change that bg color.
task-2144335
Next commit will add new cover properties entries for the bg color.
Still, we want a default `bg-primary` class. Instead of addind 3 new default
value in existing cover_property fields, the chance is taken to make a mixin
out of that field to avoid code duplication.
task-2144335
Properly set the transfer account in the company taking account the accounts defined in th company domain. We found this error because in l10n_ar module we have 3 chart of accounts based on the company AFIP responsability which actually have same transfer_account_code_prefix. For that reason it was setting a transfer account to the company which is not belongs to the current company.
closesodoo/odoo#44586
X-original-commit: d38228836b8944740f04ca355c997c4b6a346e48
Signed-off-by: Josse Colpaert <jco@openerp.com>
When there are two modules with the same name, an error is thrown
and only one of them is executed.
closesodoo/odoo#44573
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, Creating New Template from "Send Invoice" wizard doesn't update template_id on the Wizard.
In this commit, We write newly created template_id on the wizard.
closesodoo/odoo#44561
X-original-commit: 454e6ed9d956ac131d6476c95e59b2ab390df5b6
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Fixes#43705
Before this commit, There will be tracback on converting currecy if there is not date on tax line.
Now we use current date to as fallback to convert currency.
closesodoo/odoo#44559
X-original-commit: 2b88d71c6e4815334f0edaa24d6041c5facd811e
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The title of notification is the author name escaped (for security
reasons).
if (message.hasAuthor()) {
title = _.escape(message.getAuthorName());
}
When forwarded to the system notification, it does not need to be
escaped though, as the system notification is not HTML based.
Without this patch, a user named "Bob's friend" sending a message was
creating a notification with the title "Bob's friend"
Unescaping the notification body just in case but the HTML of the body
in a mail.messages should be stripped by _notifyIncomingMessage.
Unescaping will just ignored unescaped characters and should do
nothing on messages not escaped.
Fixesodoo/odoo#24846closesodoo/odoo#44550
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Improvements for custom models and some default behaviours
linked to the Studio model configurator (Enterprise task).
In a nutshell:
- mark the default `x_name` field of a custom model as 'to be copied'
- improvement for kanban views that makes it easier to user with
custom models
The interesting part is in the Enterprise `web_studio` module.
Task 2091654
Enterprise PR: odoo/enterprise#7326closesodoo/odoo#42055
Related: odoo/enterprise#7326
Signed-off-by: Damien Bouvy (dbo) <dbo@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 'new' (read: the classes not in the 'compatibility layer section')
classes of the kanban views did not allow to cleanly separate an image
header from a content container.
This commit adds such a container, allowing a very simple layout that
should work all the time for a typical 'card with left image and right
content layout':
```xml
<div class="o_kanban_record oe_kanban_global_click o_kanban_record_has_image_fill">
<field class="o_kanban_image_fill_left" name="image_128"
widget="image"
options="{'zoom': true, 'background': true, 'preventClicks': false}"/>
<div class="o_kanban_record_details">
<div class="o_kanban_record_top">
<div class="o_kanban_record_headings">
<strong class="o_kanban_record_title">
<field name="x_name"/>
</strong>
</div>
</div>
<div class="o_kanban_record_body">
<!-- some fields here (e.g. tags,...) -->
</div>
<div class="o_kanban_record_bottom">
<div class="oe_kanban_bottom_left">
<!-- some fields here (e.g. kanban status,...) -->
</div>
<div class="oe_kanban_bottom_right">
<!-- some fields here (e.g. user image,...)-->
</div>
</div>
</div>
</div>
```
Before this commit, the absence of a container for the right side meant
that the top/body/bottom were flex-growed in a flex-direction: row
element, appearing as 3 columns instead of rows.
The `FieldBinaryImage` assumes that the image mixin is used to manage
its fields - this is mostly true, until you use custom fields.
This commit makes using the 'background' option of the Image widget
possible by fallbacking the thumbnail field's name to the name of
the field itself instead of `image_128` when we're dealing with a custom
field.
- Create a product A
MTO, Buy
Add a supplier S1 and set a specific reference
- Create a product B
MTO, Buy
Add a supplier S2 and set a specific reference
- Create a SO with A & B, confirm
- 2 RFQ are created
The first RFQ is created with the correct reference, but not the second
one.
This is because `display_name` depends on context keys: it is computed
once for both products with `partner_id` set as `S1`, while it should be
recomputed for product B with `partner_id` set as `S2`.
In order to avoid this, we use `with_prefetch()` to avoid reusing the
prefetched value.
opw-2176638
closesodoo/odoo#44564
X-original-commit: d96c1910be8f242455de9b443fc9db82155b4dd1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Damien Bouvy