Because of 2917b38f28 which appeared in v9.0 but has not been adapted to the new API
afterwards, the early return was out of sync with what a search returns in new API
in v9.0: search returns a list, so must our early return
in v10.0: search returns a recordset, hence the fix
OPW 1878192
closes#26474
On a new DB with demo data, as Demo User:
- Create a partner
- Unlink the partner
An `AccessError` is raised.
The error is raised on `ir.property`, for the field
`property_product_pricelist`. An entry was indeed automatically created
at partner creation. However, a regular user is not allowed to delete an
`ir.property`.
The property can be safely deleted as SUPERUSER as long as the proper
unlink access rights have been tested beforehand.
opw-1870737
Purchase orders created from purchase agreement behave differently depending on
the agreement type.
On one hand, if the agreement is a blanket order, the vendor must be set automatically on the
purchase order and be the same as the BO. Changing the vendor is forbidden.
On the other hand, if the agreement is a call for tender, multiple purchase order can be
created with different vendors. It that case, the vendor field must be editable in RfQ states.
This commit is related to task ID 1866975.
This rev. allows to navigate, in mobile, through records in form
views by swiping.
We also moved mobile-specific tests involving a form view to the
mobile test suite, since those tests became async because of the
lazy loading of the swipe lib (in the mobile suite, that lib is
already loaded).
Related to task #34727
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Placing a list-group inside an element whose text color is forced is
buggy as the background of list-group items is forced to white and
the text color left untouched.
Before this commit, we had two different errors when data was
unavailable:
The first one is generated by Odoo: "No data to display, try to[...]"
The second one is generated by nvd3: "No Data Available".
We always want the same message.
So now, we always make some checks before rendering
the graph by calling _render.
activity.js was a little dirty with a lot of copy paste.
Most of the common logic is now in a BasicModel.
This commit also add some tests on activity view
Co-authored-by: RomainLibert <rli@odoo.com>
Previously we required one or the other to be active. We removed this limitation for SO, thus the default value should be the company setting for both on the template as well.
Task: 1876864
PR: none
This reverts commit 6e8f1fcc63.
Reverted commit broke more than it fixed.
What it fixed : Show partner info when partner is changed after the
movelines are created (very specific used case, could be considered to
be the wrong way to do things)
What it broke : dropshipping
Click on the employee app causes a traceback when hr_holidays is
installed.
With this commit, leave_date_from and leave_date_to receive a date as
expected instead of a datetime when computing the leave status.
When users create new productivity losses of type productivity or performance,
they could not be used. Only one is selected randomly. So it makes no sense to allow
that configuration.
Related to task: 58625
Rename 'Reason' in 'Blocking Reasons'.
Rename 'Effectiveness Category' in 'Category'.
Remove 'Is a Blocking Reason'.
'manual' field become a technical field.
workorder: Change label Efficiency -> Productivity.
The purpose is to make it easier for the user and remove
blocking keywork since it's already in productivity losses views.
Related to task: 58625
PR #23341
Christophe Simonis