The third parameter expects a list of field, not some random string.
This made the constraints for the fields tagged with required_if_provider to be
never checked.
Closes#12458
When grouping result the BaseModel method _read_group_fill_results add
the possible groups which had no result.
But, if the order of the group is not consistent, we can get really
wrong results. The code logic is expecting that the grouped result
gotten and the list of groups (returned by _read_group_stage_ids of
crm.lead) is in the same order.
If the _order attribute of the model is not enough specific (as was the
case in crm.stage) the inconsistent order would kill aggregation values
(displaying 0 instead of what should have been present).
opw-680952
Purpose:
Registration form needs some improvement : When there is lots of question
and answer and sometimes question is too long then view is mashed/weired
Improve the view and show one question and one answer on line, next question
and answer will come on next line,
Also change the common question/answers view, put question answer in
inline and each question/answer should come into next line
Mockup : http://bit.ly/1zpoWju
- Deletion of addon web_tip
- Creation of addon web_tour (a tour being a succession of tips)
- Creation of onboarding tours for several apps:
- Accounting
- CRM
- Discuss
- HR Expense (first step only)
- HR Recruitment
- Project
- Sale
- Various usability improvements (mainly onboarding-oriented)
Also:
- creation of a (archived by default) sample project with tasks, that the
user can activate to discover the project app.
- improvement of the simplified form view to create a new project
* Improve the JS/LESS so that its content makes the tip grow
with a bubble effect (instead of using a popover).
* Avoid flickering when the mouse leave/enter the tip or move
between the tip and its anchor element.
* Use text-align:left instead of justify
* Set the content width in JS (to a larger width) to be customizable
* Round LESS variable to avoid values like 266.6666666666
* Set opening direction according to viewport:
- Top and bottom tips open towards the right except if they overflow
the window on this right
- Left and right tips open towards the bottom except if they overflow
the window on this bottom
* Improve the 'Skip these steps' mechanism (which is easier as we don't
use bootstrap's popover anymore)
Simplified form view to create new projects
Always use quick create to create tasks
Remove chatter from project form view
Display the 'more' link in project dashboard in gray
Possibility to specify the action to execute when the user clicks on 'Create'
in the kanban view.
If set to magic 'quick_create', it opens the quick create in the first column.
Private browsing in Safari doesn't allow to store anything in the localStorage,
and it throws an error when you try to do so. This new JS module is a connector
to the browser's localStorage if it is enabled, and if not, it simply keeps its
own storage in RAM.
Purpose:
Goto 'Contacts' menu, select any Partner and click on 'Activities' state
button. The activities are read-only.
'Activities' is not created manually, so why 'Create' and 'Import' button
in Activities tree view?
'Create' and 'Import' buttons are not useful in 'Activities' view.
Rev. c9e38cae9f made the html sanitizer
stricter, and it will not badly break any attempt at composing
a good-looking mail template.
It will also strip all data-* attributes due to the default
`strict` mode, so any theme/snippets used in the template
will be dropped/crippled after saving.
mass-mailing templates are strictly meant for composing
outbound messages, and never displayed directly in users' Inbox
or published on the website. So there does not seem to be any
strict necessity to sanitize them.
Before this revision, this was not possible to write
`statment_id` on multiple journal items at a time,
as the condition:
`if 'statement_id' in vals and self.payment_id:`
required `self` to contains only one record
Since 7eab8e26 rewrite in saas-10, the rate gotten when no
res.currency.rate was present would be 0 which is not wanted and source
of issues. It should still be 1.0 as previously.
opw-681019
opw-681020
opw-681021
The `related_usage` field of `purchase.order`
is a related field to the location `usage` field,
which is defined in order to display/hide
some other field in the PO according to the location usage
This is purely a technical field, which is set only
to change the form view according to the location
usage.
This is not expected to change the location usage
through this field, this field must therefore
be set to readonly.
A change on the location usage could happen because
of the `onchange_picking_type_id`:
If the user changed the picking type, and then the location,
the usage returned by the `onchange_picking_type_id` was
applied on the location, and this must not have happened.
In addition, since `related_usage` is a related to the location
usage, it should be changed as well when the location is changed.
(in the new api, this is no longer required, the related field
is updated automatically).
This revision therefore adds an onchange on the location as well,
to handle this.
opw-676428
On the cancelation of a bank statement line
reconciled with journal items created
by the registering a payment, in addition to unbind
the move with the statement line, the statement must be
unbind from the move, and the payment must be reset
to posted.
opw-680128
In v8, the field "Order Reference" was part of the "Import-Compatible
Export" fields. This is not the case anymore in v9 since the field is
always read-only.
The fix uses the same logic than v8: dedine the field as non-readonly
for state "Draft" in the model, but always set it to readonly in the
view.
opw-676095
In some cases, several barcode widgets can be found on the same page.
This is for example the case of the stock picking: there is a widget on
the `stock.picking` model (main view) itself, and a widget on the
`stock.pack.operation` model (modal view).
In this case, when the focus is not set directly on the field which
needs to be filled in, both widgets will trigger a `barcode_scanned`
scanned event. This will call the `on_barcode_scanned` Python method
which can lead to errors/warning. For example, the `on_barcode_scanned`
method on the `stock.picking` model raises a warning in case the barcode
scanned does not match any product/package.
The fix is to make sure that the event target is located in the correct
DOM element.
opw-677506