Before this commit, all x2many fields values were sent to the server in the
onchange call. If a x2many field was not present in the view, then it
was sent as an empty list [], which is totally wrong.
A few builds fail when run in 'primetime', because the js test suite
takes more than 120 seconds (on the slow runbots). With this commit, we
increase our timer to 180s to make sure that this does not happen again.
Main page of the customer portal now contains simply a list of document
models the user can access, under a 'Your Documents' section. It is
a bit easier to read and a bit less ugly than a list of underlined
headers.
There was an extra ', which makes the options dictionary totally
invalid. Because of this, it is impossible to open the 'Purchase'
application (it causes a traceback)
There was an extra ', which makes the options dictionary totally
invalid. Because of this, it is impossible to open the 'Purchase'
application (it causes a traceback)
When several fields are modified and trigger the same recomputations, the same
SQL queries were made to determine the records to recompute, because each field
was processed independently. In order to avoid duplicated SQL queries, process
the triggers of the modified fields altogether.
This reduces the number of queries by 15% to 25%, depending on the number of
computed fields.
Replace `model.search([('id', 'in', ids)])` by `model.browse(ids)`, which is
safe because `ids` come from reading a many2one field. The performance impact
is negligible.
Steps to reproduce the bug:
-Create a tax group TX with two taxes: 15% and 5%
-Create a SO with one line and set TX on it
-Print the SO
Bug:
Only the first tax of TX was taking into account
opw:748923
When printing a report, if the company logo or report layout
is not set, it will return an action (ir.actions.act_window)
to set the layout or the logo.
But this change of actions does not forward the data parameters
to print the price list. So it raised an error.
PS: the problem comes from function "set_report_template" which doesn't
take the data parameters into account when it is called from "res.company.report.form".
opw:749724
PURPOSE
=======
Users don't find where to print the payment receipts because it's under the `Action` menu
SPECIFICATION
=============
Allow to print the payment receipt pdf directly from the print menu
Steps to reproduce the bug:
-Create a tax group TX with two taxes: 15% and 5%
-Create a SO with one line and set TX on it
-Print the SO
Bug:
Only the first tax of TX was taking into account
opw:748923
Uppercase style shouldn't be applied to all btns by default.
The usage should be set progressively, following an importance criteria.
If we design everything as important (uppercase), nothing will be
perceived as important anymore.
- Cleaner design
- Reduce element size
- Use LESS variables to simplify maintenance.
- Switch from ‘em’ to ‘ex’ measure units.
- Remove :hover state (not useful).
- Clearly show margins' size on editing
- Top margin icons/cursors: by an user point of view, adding a
margin-top will move the content 'down', so change handler's icons
and cursors accordingly
- Highlight handles during editing and if previously edited
- Vertically center handle's icon if enough room is available
Although a dark 'border-bottom' is necessary in some occasions (to add
contrast between the page's content and the navbar itself), the other
borders were totally unnecessary.
Moreover, having a complete border causes complications to calculate the
sidebar height and to manage buttons' size and line-height.
This fix will keep the border-bottom only, removing the other ones.
Compensation rules ("- 2px") are no longer necessary.
When creating an invoice from the purchase order, the later one wasn't correctly
linked anymore (and the invoice couldn't be found through the stat button).
The link is actually done with an onchange at the invoice creation.
The problem here was that the readonly attribute was set on the fields
description but it was not overriden in the view. The onchange was taken into
account in previous versions but with the new views, the correct behaviour has
been implemented: if a field is readonly, the onchange won't write on it.
PURPOSE
=======
Improve the expense sheet form view.
From SaaS 14, one expense sheet will generate one journal entry. So there is no need for a button for journal entries anymore.
The form view of the expense sheet needed to be reviewed
SPECIFICATION
=============
Remove "Account Entries" button
Clickable to see related journal entry
Before this commit, having an option on a product, the modal had every prices set to the one of the option
This was brought about by commit c8a434306f which was designed for the pricelists and striked prices
After this commit, we keep the intended behavior for pricelists while controlling that options would not mess up the modal
The prices that are displayed are the right ones.
OPW 744943
GH-17342
[FIX] website_sale, website_sale_options:fix the modal of options
Before this commit, the add quantity button were not working at all
This commit corrects the behavior by browsing the dom for anything that looks like a product section
Closes#17353
Christophe Simonis