A traceback occured when trying to create a BOM by going to
Inventory > Master Data > Products, on a product form view clicking
on the BOM stat button, and then on 'Create'.
This was a context problem: the context of the 'Products' action
was passed to the 'BOM' action without removing action specific
keys like 'default_*' or 'search_default_*'. For instance, it
contained a 'default_type' key, and as type is also a field of the
mrp.bom model, the python tried to interpret it, except that the
given value wasn't a correct value for mrp.bom.
When a button is clicked, we mix contexts coming from different
places to execute the new action. For some of them, we already
filtered out those action specific keys. This fix is simply to
make the piece of context adding the problematic keys pass though
the filter as well.
When x2many fields have to be evaluated in domains (e.g. ['id',
'in', some_x2many_field]), they must be evaluated as the list of
ids in the relation (whereas in contexts, they are evaluated as a
list of commands). Before this rev., they were always evaluated as
a list of commands.
Note that this didn't work neither before the new views.
Datapoints of the BasicModel store the data fetched from the
server and changes done (not saved yet) by the user. For x2many
fields, datapoints are of type 'list' and have a 'res_ids' key
containing the ids of all records in the relation. They also have a
'data' key containing datapoints of type 'record', representing the
records in the relation that have been fetched (with a limit set to
40 or 80 depending on the subview used). So basically, the length
of res_ids may be different than the length of data.
Before this rev., the changes in x2manys were saved under the key
'_changes' as a duplication of the content of 'data', i.e. same
list of datapoints of type 'record', modulo the changes done (it
contained the new records added and didn't contained the removed
records, whereas the 'data' remained unchanged). This didn't worked
at all when there were more records than the limit in the relation.
Indeed, when this happened, the commands to send to the server
couldn't be generated correctly.
This rev. modifies the way changes are stored in those datapoints.
Now, each change is stored as an operation. An operation could be
of type 'ADD', 'REMOVE', 'REMOVE_ALL' or 'UPDATE'. As before,
'data' remains unchanged and always keeps the datapoints of records
that have been fetched (the ones that are currently displayed in
the list or kanban subview). This way, commands can now be properly
computed.
This had a nice side-effect of fixing two other bugs linked to
x2manys.
First, when used in a context (e.g. {some_key: some_x2many_field}),
the value of some_x2many_field (i.e. a list of commands) was always
[] if the field was invisible="1" in the view, because it's
subrecords weren't fetched, and the generated commands were based
on them. Now, they are generated from the list of res_ids in the
relation, so it works fine.
Second, the x2many records are supposed to be sorted client-side,
after being read, and after each edition. This was working in the
first case, but not in the second. Now it's working even after
a record edition.
This rev. also correctly sets the 'parentID' and 'static' keys in
datapoints.
Finally, we also fixed the pager in x2manys as it was badly
displayed (small less tweaks).
Some reports require additional information to render. When
accessed in Odoo, the user has to fill a wizard to provide those
information. However, when these reports were opened in Studio,
it crashed as those information were missing (we don't pass
through the configuration wizard in this case).
This fix checks if all the required information are given before
trying to render those reports, and it displays a warning in
the logs in they are missing, which is better than a traceback.
This fix 2e18070a66595a72a9a626a196c97a689832f667 has been done in stable and some customers
wants to keep the button "Post Inventory" available all the time.
Now the button is just visible in developper mode.
opw:748347
- Create a stockable product, get 61 units in stock
- Create a SO of 75 units, validate
- In the picking, transfer only 50 units, validate and create a
backorder
- Print the Delivery Slip of the picking: it shows 61 units ordered
- Print the Delivery Slip of the backorder: it shows 61 units ordered
- Receive the 14 missing units, recheck availability on the backorder:
it shows 25 units ordered
The quantity ordered should be recomputed from the stock moves when a
partial transfer is done.
opw-747983
Rev. cf1df16aea introduced new callback
fields with restricted access. The lazy hash generation in create() was
however causing access errors for manual transactions created by users
who are not administrators (e.g. Accountants).
Those manual transactions do not typically need a callback, but checking
the presence of the callback requires a limited sudo() context.
Similarly, the execute_callback() method may be called for a manual,
non-admin transaction, and should not do anything if there is no
callback, instead of crashing with an AccessError.
The generation of the hash and execution of the callback should be done
with a normal environment, though, as these must only be used for
transactions run by the system.
opw-747536
- Update view with external_id=stock.view_move_picking_tree and remove
editable attribute on the tree view.
- Create a new picking
- Add a line (form view will open) and click on "Save and close"
=> A traceback show up since 'scrapped' was not in the form view.
- The picking location fields become readonly, and the status bar
disappears
- Save the picking
=> Error: "creation/update: a mandatory field is not correctly set :
[object with reference: location_id - location.id]"
Courtesy of @benwillig
Closes#17738
opw-748353
Steps to reproduce:
1. Create a new Stockable Product
2. Set cost price to 2.00
3. Adjust stock to 10 pcs
4. Enable developer mode
5. Go to Inventory > Reports > Inventory at Date
6. Select current time and retrieve the inventory value
Bug:
The stock valuation for the product was 0.0.
Reason:
When creating a stockable product, Odoo creates
two price history entries with the same datetime
but different cost. The stock valuation report only
takes one of them into account.
Fixes#14889
opw:747857
This is not how you check that a dict contains keys.
This also break the contract of method `get_html` that may now return
`None`, which `get_pdf` does not handle.
This reverts commit 0d2fb541e8.
The callback_eval field has a groups parameter of
base.group_system. Without this patch everyone not part of that group
ends up with an access right error when the system attempts to read
that field.
Previously this was not a problem because all code reading
callback_eval was executed with the superuser already. New code has
been introduced however that does not do this (eg. paying with a
payment.token from the backend).
opw-741181
This change will prevent the document from going from Done to Draft
In some cases a user may make that error functionally. It is only to have an additional validation
In the past, we didn't need this validations because the workflow didn't allow the use of a transition that is not defined on the correct state but since that we don't have workflow so we need manage this inconsistent action from original method in order to avoid a wrong transition.
With the flow:
- create a contact with email address set
- click on smart button "opportunities"
When creating opportunity with the plain "create button", the opportunity gets its email_from correctly
whereas
when creating an opportunity from a kanban state's quick create, only the partner is set, and not the email_from
This commit aims at setting the email_from using either way of creating an opportunity
OPW 743698
Closes#17664
Some user might be logged but not have the right to access issue or task.
Plus it does not make any sense to redirect to backend after rating a task or an issue.
OPW: 748579
In order to sort lunch order by date desc, the commit
9ab9da235f modified the
json structure (dict to array) of serialized 'previous_order'
field, without changing js code.
The previous order field should respect the new order, so
using OrderedDict does the job !
It calls `onchange_state()` on `res.partner` which was removed on
(24aba60).
It was added to `res.users` long ago (009ea40) to support a `state_id`
field on the view `res.users.simplified.form` that is no longer there
since v8.0.
The method is then never called and was crashing if called.
Closes#17772
The previous code loading the tooltip data was sending a null value
to read as id, which resulted in an access error. This behavior was
not observable in the tests because of b8c1571 which was meant to
allow giving inexistant ids to mockRead but also ended up accepting
falsy values, which was not true to the actual server.
In addition, the title of the column was wrong for unset m2o, it
displayed false, the value of the field when unset, rather than
the default "Undefined" title.
When I introduced this line in 374295b, I was working on the form
view and didn't realize I would be breaking the editable list view.
The _setMode function only updates the buttons when given the id of
a record. Since I was working on a form view at the time, I didn't
need to give a recordID to make it work since the default ID of a
form view is the id of the record itself. However, in editable list
view, the id of the view is a list of ids, so the buttons would not
be updated in this case.
When the show_address option is enabled, the display_name of a
partner becomes a newline concatenated version of his name and his
address, so the internal value of the widget is this conglomerate.
However, if one uses a keypress that does not change the value of
the input in edit mode, say ESC for example, the keyup handler of
this widget will compare the value in the input with its internal
value. If the internal value is still the conglomerate, which is
the case if the user hasn't changed the input content since
switching in edit mode, we need to trim it to compare it to the
actual input value, which is the "standard" display_name, ignoring
the magic show_address feature which is only used in readonly.
If two MOs are using the same PO, when we cancel the first MO, the
check availability of second MO is not working.
The incoming shipment of the Purchase Order has the first MO's move_id
as the destination move. When we cancel the first MO, the incoming
shipment of Purchase Order still holds the first MO's move. Because of
that reason, the check availability is not working for the second MO.
While setting the destination move for the stock moves of the incoming
shipment, it should ignore the cancelled procurements.
Closes#17701
opw-748074
Courtesy of @suganthikarunanithi
Aaron Bohy