* 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
The field was removed from the form view at af9d21b3 during a refactoring but
was forgotten in the tree view.
It makes no sense to display a field that the user can not change.
The same field was already invisible on the product.product tree view since
43977de.
Make it invisible instead of removing it to avoid breaking potential xpaths.
Fixes#12418
- added encoding to xml files
- replace search_read() with search() for _search_absent_employee()
- fixed setting first date of current month as default value for wizards
- reduce calls to <dict>.get()
Like xmo-odoo suggests, stop add Model attribute and other
variables on `self` in test cases. It makes the code unclear
and difficult to understand the test case.
Fabien Pinckaers