When we purchase products of type services,the received quantity is
always set to the ordered quantity.
We want to be able to manually enter a received quantity on service
products to have a better trace of what have been received or not.
We show the picking stat button olnly if there are picking
We show the columns qty_received, qty_invoiced and invoice_status
depending on the parent state, and not depending on the context passed
in the menu item.
* responsiveness
- Force flex-flow (avoid to apply side-chatter rules)
- Use odoo base padding
- Hide the configuration steps on mobile
* use same name in settings
* improve design
Was PR #20754
Further improves on previous commit:
- Remove some unnecessary cruft
- Make names/labels more consistent
- Make fields and their ordering more consistent in list views
- Change "active" field on rules into an "Archive" button
- Slightly improve inline doc on rules form view
- Add colors for "global" rules and "apply-for-all" access rights
('Global' is an info, but "Apply For All" is a warning, as it can
indicate an ACL problem)
- Add a tab to view applicable rules on the form view of Models
- Add a few missing fields in the rules list on the form view of user
Groups
Closes#20702
Odoo setup/install documentation needed a re-organization and an update
to reflect the latest dependencies versions.
There was too much warnings and danger signs on this page.
Finally, the structure was not the same for each install method.
* As CentOs is actually too old to handle python3 dependencies for Odoo,
rpm install method is explicitely mentioning Fedora 26.
* The "yum" package manager has been deprecated in Fedora and replaced
with "dnf".
* As Debian and Ubuntu don't ship a python3-num2words package, the
documentation must provide a hint on how to install the module using pip.
* The documentation was missing the virtualenv way of installing Odoo.
* Paragraphs mentioning configuration file were removed. The
reference/cmdline page should be updated consequently.
Purpose
=======
Currently on <record> tags, it's impossible to use 'datetime' or 'obj' when using 'search' attribute on a field.
The following example won't work:
<record id="foo" model="model.model">
<field name="bar_id" search="[('company.id', '=', obj([]).env.user.company_id.id)]"/>
</record>
Specification
=============
Use '_get_idref' to extend the accessible variables on the 'safe_eval' computation.
After entering a value in a many2one, if one clicks somewhere else, a popup
is opened to suggest the user to create (or not) a new record with the entered
value.
Before this rev, closing this popup resulted in an unclear situation where the
input was still set with the entered value but the new record hadn't been created.
This commit fixes this by clearing the input value if the record is not created.
See task#36055
Edit/create a bank account:
- Add a correct ABA number => nothing is displayed
- Add an incorrect number (e.g. with letters) => it crashes
Combining an `Integer` field with a `char` widget is just a bad idea...
opw-781069
Before this commit, an opp created from a contact via the portal was assign to
himself instead of the commercial_partner_id.
So the saleperson was not assigned to the opportunity, and the opp created was
not for the company but for the contact only.
That make sense to share the opp to the company and assign the saleman directly.
Thanks to GBR for the reporting.
Edit/create a bank account:
- Add a correct ABA number => nothing is displayed
- Add an incorrect number (e.g. with letters) => it crashes
Combining an `Integer` field with a `char` widget is just a bad idea.
Therefore we simply change the type of field and add the appropriate
contraint.
opw-781069
When we are creating a sale order line of a product that doesn't have
sufficient quantity in stock, we get a warning saying that you don't
have the quantity entered in stock.
We improved this warnig by showing the remaining quantities in the other
warehouses of the company.
Bad ISO 639-1 code
In 9.0 iso_code was guessed with `get_iso_codes` which was too simplistic
e.g. it_IT => it (correct) but ja_JP => ja_JP (incorrect)
Fixes tw:tashiropen/status/927779483041415168
On MS Windows, the mimetypes module relies on the Windows Registry to
guess mimetypes. As a consequence, when generating assets bundle for
javascript files, the mime type of js files may be wrong. In that
particular case, the Odoo user is facing an empty web page.
This commit enforce 'application/javascript' for js assets when they are
saved as ir_attachment in the database.
Since some calendar are in data, and their attendances
in an 'eval' with '0' ORM command, we need to put them
in noupdate mode to avoid duplicating attendances when
we update the module.
We chose to erase the partner_id and ref field on a picking when its
content may refer to multile records. Note that the partner_id field was
already hidden in the view of internal picking.
Use case to reproduce:
- Set a product to be expensed
- Set the expense_policy to something else than no
- Do a delivery order with a picking
- Validate the picking
-> Delivered quantity to 0 and impossible to create an invoice
if the invoice_policy is delivered_quantity
It happens due to this commit 48ea59d
What does it do:
- The move could be generated by an expense.
- If the move has 'no' as expense policy thus we won't add it in the invoice
Problem we can't guess if the move come from an expense or not (limitation).
This commit add an onchange on can_be_expense is order to set the expense
policy back to 'no' when the user uncheck it.
Courtesy of amoyaux
opw-777139
When compiling a less file in the asset bundles, we make sure that the
@import statements are 'sanitized', which is really non intuitive to
many developers. With this commit, we simply add more information to
the error message, to give them a better chance of not wasting their
time.
Thank you yenthe for the message...
Before this commit:
1. The promo code form would be displayed in the cart popover (when you
mouseover the 'My Cart' menu in the navbar.)
2. The promo code form would appear twice at the 'Payment' step at the checkout
Now:
1. The promo code form is not displayed in the popover anymore
2. The promo code form will only be shown once at the checkout 'Payment' step
This closes#20539
Purpose
=======
The original yml doesn't test anything except a read on the related fields.
Specification
=============
Replace the test by a python test that compares the values with the expected ones.
Pierre Masereel