This commit has several purposes:
- Group public/portal/employees access rights into a single selection field
- Rename the 'Employee' access right into 'Internal User'
- Remove the groups reified view on the user form and replace it by real
computed fields: Selection fields for the application groups, and
Boolean fields for the isolated groups.
For more information about the specification please check the related commits
Task ID: 32258
- Create a binary field which takes some time for computation. For
example:
```
ding_dong = fields.Binary(compute='_compute_ding_dong')
def _compute_ding_dong(self):
if not self.env.context.get('bin_size'):
while True:
3*3
for x in self:
x.ding_dong = x.product_id.image_medium
```
- Run the server with a limited CPU time, for example:
`--workers=2 --limit-time-cpu=10`
- Download the file
A JS traceback occurs, without any information about the real crash.
The error management is simply not working: `JSON.parse` is called on a
string which is not JSON-parseable.
opw-1838832
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
Purpose
=======
Allow to define users groups on a res.user with computed fields based on the 'groups_id' field.
Specification
=============
Add compute/inverse methods to manage specific groups on a res.users.
These methods should be used on fields defined like one the following cases:
1. A boolean field with the compute/inverse method and an attribute group_xml_id.
Example:
has_group_discount_per_so_line = fields.Boolean(
"Discount on lines",
compute='_compute_groups_id', inverse='_inverse_groups_id',
group_xml_id='sale.group_discount_per_so_line')
2. A selection field with the compute/inverse method, the selection got from '_get_group_selection'
and an attribute 'category_xml_id'
Example:
group_sales_team_user = fields.Selection(
selection=lambda self: self._get_group_selection('base.module_category_sales_management'),
string="Sales", compute='_compute_groups_id', inverse='_inverse_groups_id',
category_xml_id='base.module_category_sales_management')
The fields will be set according to the groups defined in the 'groups_id' field, and the 'groups_id'
field will be modified according to the modifications made on theses fields when saving the users's
form.
- Create a product named 'toto'
- Perform a call to `name_search`:
`self.env['product.product'].name_search('pouet', [], 'not ilike')`
Product 'toto' doesn't show up in the result list.
The domain should take into account that `default_code` can be `False`.
Note: the bug also occurs if the product is called 'trululu'.
opw-1837957
Remove behaviour introduced by [1], if there's a price difference the
price difference account will be used. This code block did not take into
account the fact that out move have a negative price unit, resulting in
inverted debit/credit. Furthermore, there's no special case for return
of standard and fifo.
[1] 1df16a189e
opw-1828196
- Set a default value for the field 'Activity Type'
- Schedule an activity
The default value doesn't appear.
The default value is taken into account, but the onchange override the
value.
opw-1838066
This commit adds the auto-creation journal for installed acquirers.
This is not easy because:
- The acquirers are created on the 'payment' module but are enabled only when the specific module
is installed. E.g. Paypal is enabled with 'payment_paypal'.
- To create a journal, a chart of accounts is required. However, the post_init_hook on the
'account' module makes the installation order harder. E.g install payment_paypal directly:
The module are installed in the order: account -> payment -> payment_paypal -> l10n_generic_coa.
To fix the problem, the journals are created at two moments:
- During the installation of the chart of accounts.
- At the installation of an acquirer module. E.g. payment_paypal.
Was PR #23904
Was task: 1831620
The cover image top and bottom margins should be the same on a kanban record.
The bottom margin on `o_attachment_image` has thus been removed as it is already
defined on `o_kanban_record_body` class, which makes a double bottom margin.
Task 54019
Here is an interesting scenario, involving the reconciliation tour again
(because it is our only tour that does async stuff before changing url):
- web client starts normally
- tour reconciliation starts, perform an rpc to find some id
- web client fetches users default action, it is empty, so clicks on
first menu item to load initial action, which is discuss. this will
make the web client load the action with datamanager (it should be the
action manager's job!).
- reconciliation tour rpc completes, it changes the url, this will do a
do_action
- the load_action rpc from the web client completes, it will then
perform a do_action, which will drop the action initiated by the tour
- tour fails.
The issue here is that the on_menu_action method from the web client is
not really safe, from a concurrency point of view: it performs some
asynchronous work, and then unilateraly decides to do a doAction. With
this commit, we simply add the do_action request to the action manager,
which uses internally a "dropprevious" system. This means that it will
always use the last action, just as expected.
Here is an interesting scenario, involving the reconciliation tour again
(because it is our only tour that does async stuff before changing url):
- web client starts normally
- tour reconciliation starts, perform an rpc to find some id
- web client fetches users default action, it is empty, so clicks on
first menu item to load initial action, which is discuss. this will
make the web client load the action with datamanager (it should be the
action manager's job!).
- reconciliation tour rpc completes, it changes the url, this will do a
do_action
- the load_action rpc from the web client completes, it will then
perform a do_action, which will drop the action initiated by the tour
- tour fails.
The issue here is that the on_menu_action method from the web client is
not really safe, from a concurrency point of view: it performs some
asynchronous work, and then unilateraly decides to do a doAction. With
this commit, we simply add the do_action request to the action manager,
which uses internally a "dropprevious" system. This means that it will
always use the last action, just as expected.
Here is an interesting scenario, involving the reconciliation tour again
(because it is our only tour that does async stuff before changing url):
- web client starts normally
- tour reconciliation starts, perform an rpc to find some id
- web client fetches users default action, it is empty, so clicks on
first menu item to load initial action, which is discuss. this will
make the web client load the action with datamanager (it should be the
action manager's job!).
- reconciliation tour rpc completes, it changes the url, this will do a
do_action
- the load_action rpc from the web client completes, it will then
perform a do_action, which will drop the action initiated by the tour
- tour fails.
The issue here is that the on_menu_action method from the web client is
not really safe, from a concurrency point of view: it performs some
asynchronous work, and then unilateraly decides to do a doAction. With
this commit, we simply add the do_action request to the action manager,
which uses internally a "dropprevious" system. This means that it will
always use the last action, just as expected.
When building the Windows installer, a virtual machine is used with
prepackaged python modules.
With this commit, the packaging script will try to install on the
virtual machine the python packages specified in requirements.txt.
Each package is installed individually, that way, if an install fails,
the install of the other packages continues.
At the end of the process, successfully packages are listed so that they
will appear in the build log files.
Also, the Makefile was cleaned in this commit (removal of py2exe stuffs).
Steps to reproduce the bug:
- Create a stockable product P
- Create PO and confirm it
- Cancel the PO
- Reset the PO to Draft and reconfirm it
- Validate shipment order
Bug:
- The "Receive product" button is still displayed but every shipment orders of the
PO have been treated.
NB: The field is_shipped is only used to display the button "Received product".
opw:1838539
It was possible to change manually the company of an asset, although its category would be belonging to another company and thus its depreciation lines and journal items also.
To tackle this problem, we set the company_id field of an asset as related to its category
Was PR #23498. Courtesy of Miquel Raïch
When in Python 3, then function `open` defaults to open the file in text mode
with and the encoding (if not passed) is taken from
`locale.getpreferredencoding`.
Using `getpreferredencoding` is not necessarily a good practice. Because
files might no be encoded that way.
When testing Odoo not in runbot (which has LANG set to C.UTF-8) you may get:
Traceback (most recent call last):
File "/home/gitlab-runner/src/odoo11/addons/web/tests/test_js.py", line 24, in test_check_suite
self._check_only_call('web.qunit_suite')
File "/home/gitlab-runner/src/odoo11/addons/web/tests/test_js.py", line 37, in _check_only_call
if RE_ONLY.search(fp.read()):
File "/home/gitlab-runner/virtualenvs/odoo11-MlnlRiTaP2/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4757: ordinal not in range(128)
The proposed solution is to read the file in binary mode, and decode to
unicode/str ourselves using utf-8. We don't use the encoding argument of
`open`, so that the code works in both Python 3 and Python 2.
PR #24434
- Company currency in EUR
- Create 2 rates for USD:
1.0 on 2018-01-01
0.5 on 2018-02-01
- Create an invoice on 2018-01-02 of 111 USD
- Register a payment on 2018-02-02 of 111 USD
- Unreconcile the payment
An error occurs: 'You are trying to reconcile some entries that are
already reconciled!'
In this specific case where the rate decreases, the exchange rate entry
is reconciled with the payment, so we need to keep the payment entries.
This adds the possibilty to select another account.invoice object in a vendor bill or credit note, to automatically copy its lines.
When the purchase app is installed, the same field can be used for auto-completion and users can choose between vendor bills or purchase orders (preferably PO)
Co-authored-by: dat@openerp.com
Before this, the progressbar values were not updated (both count and progress)
after archiving all the records of a column.
Multiple things have been done here to update it.
Firstly, a optimization had been done to avoid reloading the progressbar when
updating a column ; this optimization was not correct due to this precise use
case. This will update the progressbar.
Secondly, the `aggregateValues` are reset when putting empty groups back in the
datapoint. This attribute is used to compute the counter if a `sum_field` is set
on the progressbar widget. It needs to be reset because the loop that computes
it won't iterate on empty groups.
Eventually, the mockRPC of the progressbar route was not taking the `group_by`
argument into account (probably a typo).
Use case fixed: manual reconciliation through the account.move.line list of items with several currencies, that will create a full reconcilation with several exchange rate entries to balance the amounts in all foreign currencies. Unreconciling these lines was wrongly creating an account.move with a lot of lines with debit = credit = amount_currency = 0.
Usecase to reproduce:
- Create a product A with a qty on hand 5.5
- Create a delivery order with an initial demand of 5.5
- Validate it with a qty equals to 5.95
The initial demand is updated to 5.951 then reduced to 5.95
and a backorder is created with an initial demand of 0.001.
That should not happen since I process extra quantities.
It python 5.95 - 5.5 = 0.4500000000000002 and the float_compare
use a round UP method thus it returns 0.451 and the following
flow is based on a wrong value.
In this case a float compare is used before the float round, so an
HALF-UP rounding should be okay since a very small quantity diff should
be filter by the compare.
Fixes#24401
... by setting it 'btn-default', because users hesitate between
that button, and those in the control panel.
Task 32950
Co-authored-by: dbh <dbh@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>
Rev. 374af56 changed the way 'button' nodes are rendered in basic
views (form, list, kanban). As a consequence, their 'name'
attribute wasn't transmitted to the produced html elements anymore.
However, this attribute is very convenient to debug views, and to
write selectors in tests. For instance, it broke the test added by
rev. 8d17a2a once forwardported in master.
This commit reverts 1ce5bea.
- Company currency in EUR
- Create 2 rates for USD:
1.0 on 2018-01-01
0.5 on 2018-02-01
- Create an invoice on 2018-01-02 of 111 USD
- Register a payment on 2018-02-02 of 111 USD
- Unreconcile the payment
An error occurs: 'You are trying to reconcile some entries that are
already reconciled!'
In this specific case where the rate decreases, the exchange rate entry
is reconciled with the payment, so we need to keep the payment entries.
When a scrapped move is part of an open picking, it was not possible to
unreserve the picking. A scrapped move is done and scrapped ; this
combination should be allowed.
opw-1835186
- Create the following reconciliation model:
Line 1 is 50% of amount, tax is 20%
Line 2 is 50% of amount, tax is 0%
- Use this reconciliation model to reconcile an amount of 1000.
4 lines are created:
- 2 lines for base amount (500)
- 1 line for the 20% tax (100)
- 1 line for the 0% tax (1000)
Obviously, the last line is incorrect, and should be 0.
opw-1837049
This feature has been removed in rev. odoo/odoo@e533085 but this commit
reintroduces it. It was considered as "too dangerous" for new users.
Instead of removing the feature, a confirmation request has been added to warn
the user about his potentially harmful action.
The same warning has also been added in List view when archiving records.
Task 60393
Co-authored-by: Mohammed Shekha <msh@openerp.com>
The calculation of the delivery cost for a sale order / invoice was not correct when
free over a limit had been satisfied.
Steps to reproduce the bug:
- Set a delivery method DM with a fixed price = 10.0 and free when the amount of the order exceeds 100
- Create a SO for an amount of 150 and set on it DM
- Confirm the SO and deliver it
Bug:
A SO line with DM was created with a fixed price of 10.0 instead of 0.0
opw:1838070
when navigating with the keyboard, using the ALT key is the trigger
for most of the access keys. In Firefox on Linux, this prevents a number
of existing shortcuts (like ALT+Left arrow for browser back).
This fix allows browsers to execute those shortcuts.
Note: in Firefox on linux ALT+F E V S B T H are assigned to menus and
cannot be stopped, removing the keypress handler does not change
anything.
Before this fix, when going on the graph view from the dashboard view (
using the fullscreen button on dashboard), the focus is on the search
input, hitting the tab key creates a crash.
This fix gives a default implementation of giveFocus to the
abstractrenderer so there is no crash.
When doing several grouping quickly (or if the system is slow) on the
pivot view, we may try to display data that now doesn't corresponds to
the current selected groupBys.
This commit ensures that when we load data of the pivot view, we drop
the previous data loading that are currently being carried out.
Without the fix, the added test failed with:
TypeError: Cannot read property 'length' of undefined
because the test does:
- select one level of group by
- select two levels of group by
- resolve the first level of group by
- resolve the second level of group by
Without the fix, we would try to display the data for one level of group
by when the pivot view had two levels selected.
With the fix, displaying the first level of group by was discarded once
a second one was being requested.
opw-1825892
closes#24396
If the user has limited_access, download_security field was not read due to the
override of check_field_access_rights and so the field not set.
When you try to access/read it, you got: Selection is not iterable.
Now we check in sudo the download_security.
We also add the **kw that should be present in all routes.
Avoid: "slide_download() got an unexpected keyword argument 'debug'"
We also remove this controller from the sitemap.
The settings view is supposed to open a new record on the model
res.config.settings, perform the default_get and onchange calls, then
display the result.
However, once this is done, if the user then clicked on some links
(which do save the current record and navigate to another action), then
click on the breadcrumbs to come back to the settings view, then the
settings view will reload the current record, which has an id, and this
also will update the url.
This could be a problem. For example, in a multicompany settings,
reloading a settings view from an id will reload the settings for a
given company, even if the user changed its current company.
To fix this issue, we make sure the basic model for the settings view
'forgets' the res_id key, so it will be compelled to actually reread a
new settings form record.
The _mockMessageFetch method was changed in the mockserver in saas11.2.
The forward port then obviously broke this test, which depended on the
fact that it returns an empty list.
A dependency to libsass was added in debian package and in the docker
file. The Odoo nightly builds of the deb package was failing because
this lib is named libsass0 in Debian.
Finally, this dependency is not required because python3-libsass already depends on libsass0.
qsm-odoo