For one2many and many2many fields, you have several ways for specifying
a view other than the default one:
- to write the arch of the view in the field tag
Example:
<field name="many2many">
<tree>
...
</tree>
</field>
- to write xmlid of the view in a specific key (*_view_ref)
in the context of the field.
Example:
<field name="many2many" context="{'tree_view_ref':'module.tree_view_ref'}">
Before this fix, the second case didn't work.
the default view was loaded instead of the one passed in the context.
In fact, this context is evaluated after the loading of the record but
we need some static keys to load the view (before fetching the record).
Each REPL python shell behave differently depending on the exit method.
Force a rollback at the end to avoid inconsitent behavior.
Thanks to Harry Jollenbeck for the report: https://www.odoo.com/groups/59/26318707
When we try to archive a kanban column we get a traceback when the field
'active' exists on the model but not in the view.
This traceback is caused by an unecessary check of the active value of
the record.
To fix it, we apply the 'active' value on all records, and not only on
the ones where active value changed.
The field partner_id on stock.picking is not a required field so it
would possibly cause error when getting the name of the report since
partner_id was used in it since efdb5373c3.
opw-728549
Traceback when:
* click on first row of calendar
* move an event somewhere else with drag and drop
* click on the mini calendar
* filter from the control panel triggers a traceback
* add an attendee: traceback
* day/week/month: traceback
* cannot add a leave, the fromViewDialog does not open
* one day oo server-side when select all day
The client must receive the tzOffset to apply this on all hours.
To use the date picker we must change the date to apply the change
in the user's tzOffset, without this change the result is wrong.
For datetime widget we must change like it to avoid max stack error.
The server send the tzOffset, if it's undefined, by default the client
use the browser time offset.
Every test are change to use tzOffset.
A test is added in calendar to use the click by position for the
fullcalendar lib. This test create and drag and drop an event to check
timezone error and error when we use default value in the context.
Use formating date like 2026-04-04T08:00:00Z instead of 2026-04-04 08:00:00
is important for phantomjs, because it's crash without information if the
formating is not the standard format.
For the parsing, when the client receive a server date the date is utc
formating but when it's parsed from the client is in the user's timezone
SIPS payment has two limitations:
- A payment reference can only be used once, even if the payment was not
proceeded
- A payment reference can only contain alphanumerical characters
These limitations do not fit the payment process which:
- Reuses existing transactions
- Introduces a `-` character when creating a new transaction for the
same order.
First issue is solved by an ugly hack since there is no link module
between `website_sale` and `payment_sips` in order to override the
behavior of `sale_get_transaction`.
Second issue is solved by modifying the character to `x`. In this case,
we could consider overriding the method `get_next_reference` in
`payment_sips`. However, this method is called before the creation of
the transaction, and we should do a crappy workaround using the context
to get the `acquier_id`.
opw-728209
The field widget html wasn't implemented yet in the new views. A
very basic implementation was done in addon web. It only handled
the readonly mode so that the field were displayed in studio.
This commit removes this basic implementation from web, and re-
introduced the old one, converted, in addon web_editor.
In a form view, if a one2many list view contained a many2many
field (e.g. widget many2many_tags), the commands for the embedded
many2many weren't generated for newly created one2many subrecords,
so this field couldn't be saved.
When you do a group by on field that is not present in the view,
this.fields contains all the model's fields, not only the ones present
in the view.
As we use the method 'has_active_field' to check if the field active is
available in the view, the value is not always correct.
To fix this we take the fields_view fields instead of fields.
This bug has been introduced in rev: https://github.com/odoo/odoo/commit/5b4f7c13f32f36d86805eb7865d8a077746181d8
- Create 3 products (A, B & C) with tracking set to 'serial'
- Create a BOM: A consumes 1 unit of B and C
- Create a MO for A, create the lot A1 for the finished product
- Create another MO for A, use the existing lot A1 for the finished
product
- Try to mark the MO as done => you get an error
- In the finished products tab, change manually the lot, for example by
creating A2
- Mark the MO as done
- Open the Upstream Traceability => under the MO, there is nothing, the
traceability is lost.
The `check_finished_move_lots` method takes care of setting the
`lot_produced_id` on the `move_raw_ids`. However, when changing manually
the finished product lot, this modification is not propagated.
Therefore, when posting the inventory (`post_inventory`), the line:
```
move_raw.move_lot_ids.filtered(lambda x: x.lot_produced_id.id == lot)...
```
doesn't return any lot. Consequently, `consumed_quant_ids` is empty, and
the traceability is lost.
opw-724944
The method has not been correctly ported to the new view (in the new
model in this case).
The change (on the color) needs to be notified to the model before
updating the record.
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
Ronald Portier