The widget_x2many tour uses the discussion model to test one2many
and many2many widgets. The tour clicks on an item of the menu which
opens the discussion model with the discussion_form_2 view (in create mode).
Then, it clicks on the view_switcher to display the list view, and clicks
on an item of the list to open a previously created record.
In the new design, there is no more view_switcher in form view. This flow
is thus unfeasible. This solution changes the menu action so that it
directly opens the model with the list view, on which we can click on the
record to display in form view.
This rev. generalizes the notions of FieldOne2Many to FieldX2Many and of One2ManyViewManager
to X2ManyViewManager. The same logic is now applied both for One2Many and Many2Many fields.
This allows Many2Many list and kanban views to have a pager, as the pager is instanciated
by the view, on demand of the ViewManager.
Apply the same style to many2many form_field as for one2many ones.
Make the sales_team cards for team members clickable.
Add "position: relative" to sales_team cards for the cross to be correctly
positionned. Inline style is not the right way to do it, but for the sake
of consistency, it is ok. A better commit should come to remove this inline
style from all x2many kanban templates.
The number displayed in the Sales button shows the number of sale order lines confirmed
for the current product.
The number displayed in the Purchases button shows the number of purchase order lines
for the current product.
closes:#7107
this is not necessary anymore, with the new kanban view. It also
paves the way for further changes (soon to be done): using a viewmanager
to instantiate the many2many kanban view
More precisely, installing a theme module is valid if: there exists a module
such that all theme modules already installed or to be installed, correspond to
one theme module and its theme module dependencies.
Closes#7147
This is a really difficult optimization. Based on various benchmarks
and some hard thinking, we discovered that this change will shave
approximately 100ms for each drag and drop performed by a normal user.
We believe that this is a safe optimization in most cases (but we didn't
test it on some architectures, such as ARM or Solaris). It is also
compatible with most SQL JSON-enabled databases.
Add a `delivery_type` selection field on delivery.carrier.
The default is `grid` i.e. a static pricing grid with rules
to compute the delivery costs.
Future module will however be able to extend the `delivery_type`
selection to add new keys, such as `fedex` or `ups` and provide
custom implementations for the various API methods, as described
below.
In order to add your own external provider, follow these steps:
1. Create your model MyProvider that _inherits `delivery.carrier`
2. Extend the selection field `delivery_type` with a pair
('<my_provider' , 'My Provider')
3. Implement API methods as required:
<my_provider>_get_shipping_price_from_so
<my_provider>_send_shipping
<my_provider>_open_tracking_page
<my_provider>_cancel_shipment
As of version 8.0, search_count method has been implemented
Usage in this place is not needed though,
as we just need to know if there are messages in domain,
not the exact number of them.
Due to that we replace method search_count with search and add a limit of 1,
which provides better performances.
Fixes#6670Closes#6679
- Remove the Bid notebook on the purchase order form.
- Add a message on the chatter to display the field Bid Received On
- Move the field Bid Valid Until under the Order Date field, displayed only if Bid Received on is filled.
- Remove Invoice Received Checkbox, as there is now a stat button to display the information
- Add a default filter "To Do" on the RFQ and purchase order views, which displayed all the record not in the states done or cancelled.
- Changed several labels, and reorganized some options in the configuration.
When invoicing in currency A and being paid in currency B, the exchange
rate between those currencies might differ between the invoice date and
the payment date.
When reconciling, invoiced amounts should be converted using the invoice
date exchange rate.
opw-640248