- add a filter "production locations" on stock location
- add an action returning the production stock locations
- display a link to this action in the product category views in stock
account so users can easily set the correct accounts on these
locations
- set valuation journal an account before the others in the product
category form
Task-2161057
closesodoo/odoo#43762
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose
=======
Now that we have a new timer mixin that offers more possibilities
than what was currently implemented, we can reuse it in the timesheet
management module.
TaskID: 2149450
Purpose
=======
The timer mechanism is already existing on timesheet.
We would like to introduce it on helpdesk.ticket too, and
probably on other models afterward.
On the other hand, only one timer can be launched on a single
timesheet currently, shared amongst the different users.
This commit introduced a new mixin on which
- Each user can launch a timer on each record of the models
inheriting the mixin.
- Launching a new timer on a record pauses the timer of the
user that could be already running.
- The mixin brings methods to start/stop/pause/resume the
timer, that could be overridden to implement a specific
behavior for the related model, for example create a
timesheet entry.
TaskID: 2149450
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>
Currently when creating an SO without any products and creating
down payment for that creates a traceback.
so Fix traceback when creating an invoice for sale order with an empty
product. when there is no orderline then do not get the sequence in down
payment line to make down payment line at last in sales order.
Task-2181464
closes odoo/odoo#44645
Closes: #44491
X-original-commit: 5e3e127187130a3d6dac98920564598a05d9c627
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
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
We had a default warehouse_id on the users to allow
a better stock managment based on the sale person.
The warehouse_id on a sales order is now computed from
the property_warehouse_id field on a user.
If the user doesn't have a property_warehouse_id set
the warehouse_id on the sales order is the one with the
smallest sequence number in the company of the SO.
Task-2166382
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.
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>
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>
fja-odoo