When validating a vendor bill, we want the product
with expense policy set to be reinvoice on the open
sales order matching the analytic account of the invoice
line. Applying the same mecanism for customer invoice
does not make sense, as we might confirm a SO and validate
its invoice, we don't want a new SO line to appear (avoid
loop).
Unfortunately, since a long time, this is possible in Odoo,
and really make no sense. We should only take negative
analytic lines (coming from vendor bills and expense, not
the customer invoice) into account for adding SO line.
This commit correct this problem to avoid having
many null SO line created on customer invoice validation.
All test cases are correctly written, but there was no
check to prevent this mecanism to be apply on customer
invoice.
Issue:
domain="[('date','=',time.strftime('%%Y-%%m-%%d'))]"
is converted into a domain equal [('date','=','%2017-%12-%12')]
instead of [('date','=','2017-12-12')]
Odoo 11 comes with unified features for Project Tasks and Project
Issues. Specifically, issues were retro-fitted into tasks, and saw their
specific features added to the features of tasks.
During this refactoring, the portal controller for issues was superseded
by a unified portal controller for tasks, via
623ea43268
One case was lost in the process: portal visibility of
tasks/issues/things that are individually followed by customers, without
the customer following the project itself.
This is important for `transversal` projects, such as a "Helpdesk"
project common to all customers, where each customer only sees their own
issues.
This commit restores the feature, previously added to issues by
1cc8252a95
Note: this clearly requires a proper regression test, to be added soon.
- Create a custom field
Field Type: monetary
Tracking: Always
- Install any module
A crash occurs in `_instanciate_attrs` since `attrs` is `None`.
In some special cases, the instanciation of the attrs of a field is
delayed at the very end of the setup. For example, in case of a Many2one
for which the comodel is not yet loaded.
Therefore the override of the method should take this case into account.
Closes#22922
opw-815185
When creating an extra move, the price_unit field was not copied. It is
normal since the field is copy=False following rev[0].
But there was a side effect: let's say you order 1 product @ $10 and you
receive 5. The received quantity field on the purchase order line is
correctly set to 5 and the valuation inside the stock is correctly set
at $50, but on the picking there is one move line of 5 and a move a 4
and of 1, instead of one of 5. Note that in v10, the pack operation
would be split between the original move and the extra move, but in our
case the extra move is merged back in the original move, so we don't
need to split the move line. The split mechanism is there only when
working with moves without picking[1].
The issue here is that the moves are not merged because they do not have
the same price unit (5 and 0). We thus copy the unit price when creating
the extra move.
When creating a backorder, the price_unit field wasn't copied either.
It's not important when working with the classic flows (the link to
purchase_line_id is kept), but to be consistent we also copy it.
[0] https://github.com/odoo/odoo/commit/a4740861d3fdbecc8b1171b7d2072697e8a36258
[1] https://github.com/odoo/odoo/commit/561b3461a020021d911999cb41154f158b069a1d
New rights were applied on hr.employee with this commit https://github.com/odoo/odoo/commit/2d777d5ade94f4a80862608e2807660f289d9923
Since, users with limited rights would see a read error when submitting an
expense to manager.
Indeed, when clicking on "SUBMIT TO MANAGER", it opens the view form for
'hr.expense.sheet' that trigger an onchange on employee_id to set the
employee's private address to the expense.
Since restricted users can't read that field, the rpc call to that onchange
was throwing an error resulting in:
1. Showing an read error when entering form view that user could close to
save anyway.
2. The hr.expense.sheet address would not be set as it should have
Now, we give sudo rights to read that field during the onchange
OPW-815786
When a picking is in 'Waiting Another Operation' state, there is no
possibility to force the validation. In v10, it was possible to force
the reservation, which is not possible anymore.
Therefore, we make the 'Validate' button accessible in the mentioned
state.
opw-817234
The generic payment form introduced in 11.0 has changed the way we collect payment and so does the code.
The route /website_payment/pay hasn't been changed to support the new payment form.
This commit fixes this.
It also fixes a bug for when a customer tries to create two transactions with the same reference.
Before the patch, validating a picking where one of its move do not
have any quantity done nor quantity reserved resulted in the complete
validation of the said move. This doesn't make sense and does not do
what the help in the wizard indicate (process only *reserved* quantities).
We also use this patch to clarify what the tests on this workflow is
doing (test_immediate_validate_*). We completely replace the 3 as it was
testing the `force_assign` mechanism, which methods are still present in
v11 but unused. Instead this test is now testing the failing flow this
commit is fixing.
We thus adapt the `process` method of the immediate transfer to only
process the move lines (move line = reservation). We also fix a case
where nothing is reserved and nothing is done. In this case, the
backorder wizard should not opens but instead an UserError telling the
user to either cancel or process something. The testcase for this flow
is test_immediate_validate_7.
With these changes, the test `test_04_create_picking_update_saleorderline`
was failing because one of the items in the so lines was a stockable
product without stock. So before this patch, everything was processed,
now there's a backorder wizard. We complete the patch and duplicate it
with enough products in stock, so that the backorder wizard is not
needed.
opw-815056
opw-808126
Steps to reproduce the bug:
- Connect as demo user
- Create a repair
- Add a product
- Save
Bug: An access error was raised because the demo user has no access rights
to write on product.product
opw:816645
It happens from time to time that someone use "Format" on the
web.layout template. Thus:
```
<script type="text/javascript">
var odoo = {
csrf_token: "<t t-esc="request.csrf_token(None)"/>",
};
</script>
```
becomes:
```
<script type="text/javascript">
var odoo = {
csrf_token: "
<t t-esc="request.csrf_token(None)"/>",
};
</script>
```
breaking a number of things on the frontend and everything on the
backend.
On a pure javascript content, we could wrap it with:
```
//<![CDATA[
/* javascript content */
//]]>
```
but in this instance we still want the xml to be processed.
This commit avoids formatting XML containing a script tag.
opw-815865
closes#23164
Before this rev., an issue occurred on grouped editable list views
that became ungrouped after a reload (i.e. when the grouped part in
the search view was removed). In this scenario, the click handler
outside the list used to leave the edition wasn't bound (because
the list was grouped at the beginning, and thus not editable). So,
it was impossible to leave the edition, even by clicking on 'Save'.
Fixes#23061
This commit only concerns the community webclient. The user can
edit the company data by clicking on the company logo displayed
in the submenu (left bar). When it does, the logo's url must be
updated to force the logo to be reloaded.
The last part doesn't work since the new views, as it uses an
hook of the form view (called when it is saved) that doesn't
exist anymore.
This rev. adapts the code so that the logo is reloaded when the
edit menu dialog is closed.
It also ensures that the logo is properly reloaded by specifying
the timestamp in the img url as a query string parameter instead of
an hash param, since changing the hash doesn't seem to be enough to
fool the browser's cache anymore.
Before this commit:
If you changed the URL of a menu linked (m2o) to a website page and the new URL
was already taken by another page, it would edit the menu.url and the
menu.page.url resulting in the menu's page having the same URL than the already
existing one.
Now, if you edit the URL of a menu linked to a page and the URL is already
taken by another page, we will simply change the menu/page m2o relationship
without writing on the menu's initial page's URL.
In chatter, also linkify URL with IP address as domain name like it may
be in other part of Odoo (eg. plaintext mail received).
With this change, an URL:
http://192.168.0.1:8069/web
would be linkified.
opw-816175
closes#23153
The correct model description is set in hr_payroll.
The model does not change when installing a new module ("payroll run" was not
very meaningful anyway)
Trying to create a module through the interface will blow up as
computing the `desc` leads to a concatenation of the module's addons
path, the module's name and a hard-coded path, which does not work as
the module does not have a name yet. This creation attempt can be
performed as the admin through m2o fields.
Given said creation through the UI doesn't really make sense, disable
it on the relevant fields.
Fixes#23059
Purpose
=======
The warrants are not displayed on the same payslip than common salaries, and therefore it is confusing to see all the different concepts matched into the same payslip.
Before this commit, the uom defined on the sale order line and on the
purchase order line was propagated to the moves. This is not the
behaviour of v8-10 and may confuse the stock operator (one time he's
working in dozen, another time in units for example). It also leads to
rounding issues if the configuration is not adapted correctly (product's
uom is in units, sale order line is in dozen, the rouding precision on
the uom is left to their defaults, now if a dozen is partially available
there's a good chance converting back and forth form dozen to units will
break).
An ir.config_parameter was added to restore the behaviour before this
commit.
Overly attached cache's overhead turns out problematic. Clearing the
cache after batches of records keeps the cache overhead low and does
not change performances.
Explanations:
env.cache is 3 levels of maps {field: record_id: {env: value}}, where
env can be either an Environment or a pair (cr, uid) depending on the
field's dependency on the context or not.
This can be an issue when the current request loads many fields in an
enormous number of records in a single environment. The (PaaS) case
here was the export of a res.partner field from 36358 records in a single
environment[0]:
* prefetch expanded the single field to 68, leading the base `cache`
to have 68 entries. getsizeof(d<len=68>) == 3360 (3kB, which we will
soon see we can ignore entirely).
* *each* of these entries would hold a map of 36358
records. getsizeof(d<len=36358>) = 3146016 (3MB), 68 times = 213MB.
* finally each record entry is also a {(cr, uid): value}, here the
dicts have a single entry which makes them 280B, and their key is a
2-tuple "worth" 72B, or 352B/record/field, or 352 * 36358 * 68 ~
870MB[1].
For a total of ~1GB, which is roughly the issue we can observe.
Future possibilities: extract the cache-clearing iterator to be more generic
and available on BaseModel directly? Or even make the default iterator
batched & cache-clearing?
[0] note that sys.getsizeof only provides the size of the object it's
called on, it is not recursive
[1] slightly more in actuality as there's some variation between the
leaves depending on the field type e.g. M2O values are a 1-tuple
adding 60B, ...
Fixes#22475
With more than 1 level of generic type, the "closure" of generic
parameters would get tokenized by python as a single right shift (>>)
rather than two gt (>, >) leading to our own tokenizing pass getting
lost and blowing up.
Fix by explicitly recognizing and splitting (>>) into (>, >). We could
consider writing the entire tokenizer ourselves instead of
post-processing Python's but given the entire post-processing function
is currently shorter than just Pythons' tokenizer's regexes...
Anyway issue found by vsc while trying to write better docstrings.
Since the new year, the graphs in sale dashboards were not displayed
properly when grouped by week. This was because the computation of the
number of weeks in 2018 gave "1" as a result as this was got from the
week number of 31/12/2018 which is in fact in the first week of the
ISO year 2019.
This commit solves the problem by using the 28/12/xxxx which is always
in the last week of ISO years.
opw-816758
If a record is deleted *and* has property fields, the deletion of the
property fields will trigger the various recomputes before the record
itself has actually been deleted, and thus stuff which depend(ed) on
that record will be recomputed under the assumption that the record
still exists, which probably will not work.
Under the assumption that the same issue would occur when deleting
more than one batch of records (unlinking the data, values or
attachment would also trigger a recompute before the proper end of the
function and could lead to incoherence, e.g. some of the records being
deleted being visible to recomputes), lift the entire effective body
of the unlink into a norecompute context, to ensure that only the very
final recompute (from the top-level unlink) is actually triggered.
opw-807036
Josse Colpaert