In 599bd509 for inline image in a mail the `Content-Id` of the
attachment was used as the file name to avoir an issue of several inline
images with the same name only displaying the first one.
This solved the issue but with it the file name when downloading the
image were lost as well as the extension which can be an issue.
This changeset refactor the code so the behavior stay the same but the
original file names are kept.
opw-725305
Issue: when a field is computed on a new record, the record is not marked as
"being computed", and it could therefore be invalidated. The fix consists in
using the standard method that marks records before calling the compute method.
button will only be visible if the move_line are not reconciled yet
This button will allow user to register a payment and then reconcile it with multiple invoices in the payment matching view.
Was PR #15157
By unticking the "Use Existing Lots" checkbox on the pos picking type,
you can choose not to enter any lots/serial numbers in the pos. This
way, the picking will not specify the lots either and the system will
take the quants and lots according to the removal strategy.
Before, when the POS order created the picking, it would not be set to
done when one of the lines contained a product that required lots.
This was to avoid the case where the lot given in text in the POS
order would not correspond with a real lot in the database.
So, in order to not annoy the user when he gives correct lots, we
validate the picking when we can find back the given lots in the
system.
opw-698060
The POS support for tracked products implemented at
8f39c652c6 was mainly meant for products
tracked with serial numbers. In theory it would also work for lots as
long as the lots were only sold in integer quantities. One could specify
the same lot multiple times.
For products tracked in non-integer quantities this wouldn't work
however. This commit makes the POS handle lots more like the stock
module. When a product tracked in lots is bought in the POS you can only
specify one lot number. If a product is sold from multiple lots then
multiple order lines have to be specified.
Fixes#15325
Demoted to library in Python 3, see if uses can be replaced by more
specific construct, just import functools.reduce otherwise.
Futurize fixers:
* lib2to3.fixes.fix_reduce
This commit prevents from erasing the origin part of the url
when the tour manager does a redirection. This was an issue in
phantomjs if it allows local url as in this case, it will try to
load file://<tour_url> instead of <origin><tour_url>.
One could want to render something else than a `button` in the
buttonbox (even if the name seems to imply that it will contain
buttons).
In this case, we render the method corresponding to the tag instead
of a button.
- Create a product invoiced at delivery (A)
- Create a SO with Product A, confirm => the invoicing status is
"Nothing to invoice"
- Create a down payment => the invoicing status is "To Invoice"
Since the down payment is added as a product, its invoicing status
influences the global invoicing status of the SO, while it shouldn't.
opw-727936
This branch introduces a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable
in different conditions (in studio, or in the frontend), and to make
our lives easier.
Some important points are:
- we have a brand new testing framework (still QUnit based)
- kanban view (formerly in web_kanban) moved to the web addon
- calendar view (formerly in web_calendar) moved to web as well
- tree view was removed
- each view is now separated into 3 parts: the renderer, the model,
the controller (so, actually a kind of MVC)
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm, mge,
fwi, adr
The price of the product was not updated according to the pricelist
when changing the qty of a product in the cart because the context
of the product was not correctly set before calling function
_get_display_price in _cart_update.
But this part of code seems to be redundant with _website_product_id_change.
opw:728312
- Create 2 stockable products (A & B).
- Sell these products in the POS, but leave the qty of Product A to
zero.
- Validate and pay
- In the backend, return the products and register payment
Two pickings are created, and one of them is empty.
Products with a quantity of zero are not included in a picking.
Therefore, we should ignore them when the pickings are created.
Fixes#16292
opw-728101
Debounced fields do not notify their environment each time their
value changes, but rather wait for a given delay after the last
change. Input fields allowing the user to type text should be
debounced. The AceEditor is one of them.
Note: this should be tested, but i can't find a way to simulate
text entries in the ace editor.
In the new implementation, the type is checked to prevent loading
a view type that does not exist.
In the old implementation, the type was ignored resulting in a graph view.
So, before this commit, some views were no longer loaded.
The 'pivot' type should not be used since there is a dedicated pivot
view.
`makeRecord` is now asynchronous as it will load data
for relational fields (X2manys and many2ones if `display_name`
is not fetched).
This change has implied a refactoring in all `makeRecord`
occurences to adapt with the returned deferred.
It might happen that some code in a widget (callbacks given to
other function calls) is executed after the widget's destruction.
For example, trigger an event up with a callback in option, the
event is handled by a parent that performs an rpc, meanwhile, the
child widget is destroyed, then, the rpc returns and the parent
executes the callback.
This shouldn't happen, because it means that the callback is
executed for nothing. Worst, it crashes if the function _rpc is
called inside the callback, because the widget being destroyed,
there is no parent to handle the request, and _rpc thus returns
undefined.
This rev. protects the code from crashing by making _rpc return
a pending deferred instead of undefined.
Before this commit, clicking on buttons did not reload the current
record, which is good. However, it kept the reference to the record
after saving, even if that record could have been changed, which is
definitely the case when starting from a new record and saving it (it
will have the correct res_id, which is really important).
When saving a new record, with the option reload=false, a datapoint in the
basic model could be left in a wrong state: the x2many fields were
deleted, with all the changes, but the values in the data key were still
null, which means that the x2many field has no valid corresponding
datapoint, as far as the basicmodel can see.
So, with this commit, we make sure to push the changes into the data, so
the datapoint is in a proper clean state.
In some case ´default_get´ returns values for relational fields that are not
in the view so we cannot create a datapoint for these field. Furthermore, we
cannot discard these fields in order to save their values correctly in the newly
created record.
When the ´default_get´ returns default values for a x2many field, it needs
to be set as changed fields in this x2many field. Previously, it was wrongly
assumed that these changes were non existant.
When clicking on a button in a form view, the current data should be
saved but the form view shouldn't be re-rendered in readonly.
Before this commit, the view was re-rendered, causing a weird glitch
in dialogs as buttons that were supposed to be moved to the dialog's
footer appeared inside the view when the button was clicked.
Also forces the default mode in form view to readonly, so that it is
correctly redrawn in readonly when coming back using the breadcrumbs.
Commit odoo/odoo@a24793962 adds some steps to the x2many tour.
This part of the commit had been deliberately moved aside for a
while in the new views branch, as what was tested didn't work yet
back then. It does now, so we re-enable those steps.
When a field with an onchange is changed, if there is a context
defined on the field in the arch, this context must be added to
the context sent with the onchange RPC.
Before this commit, we lost the functionality of editing records top or
bottom. However, it as almost ready, but we needed to change the way
commands are generated, to respect the actual order in the UI.
Also, the mock server needed to be updated, to make sure he also save
the new ids in the correct order.
Those steps had been deactivated because the onchanges didn't
work well back then. Now, everything that is tested by the tour
works fine, so we can re-enable it entirely.
When there is an onchange on fields of a one2many, the data given
to the onchange RPC should contain an additional key for the
corresponding many2one, mapping to the current data of the parent
(main) record.
This wasn't working before this rev. for new o2m records created
when the one2many wasn't editable inline (with a list view
editable), because in that particular case, the reference to the
parent record wasn't specified correctly.
Nicolas Lempereur