This rev. fixes 2 issues about many2many fields displayed with
an editable list view, occuring when the user edited some values
in the list.
First, the many2many field was re-rendered each time one of its
sub-widgets triggered a 'field_changed' event, and thus the row
the user was editing was no more in edition and the focused field
was no more focused. This was quite annoying.
Second, when the user saved changes made in the editable list view,
only a command 6 (REPLACE_ALL) was sent, so updates of subrecords
were never saved.
Before this rev., if you opened a form view with, e.g. a float
field, that is unset, and then click on edit, then save, it
actually saved the new value for the float field (being 0),
whereas it shouldn't do any RPC as nothing changed.
This is because the former code couldn't detect if the value "0"
in the input is there because the field is still unset or if the
user simply set it to 0.
The process of evaluating a domain is not really difficult, but the hard
part is getting the evaluation context right. The evaluation context is
supposed to contain informations coming from various sources (active id/ids,
session context, ...). Before this commit, we just ignored the context coming
from the action.
This could cause many problems. For example, in the Inventory
application: create a picking, add 10 ice cream in initial demand, force
assign, click on scrap. A form view should be opened (with the context
coming back from the button_scrap method). In that formview, there is a
many2one Product. Clicking on it should perform a name_search with a
domain looking like ['id', 'in', [64]]. This domain is the result of
the evaluation of "[('id', 'in', context.get('product_ids', []))]".
Before this commit, product_ids was ignored, so the domain was always
['id', 'in', []].
In this commit, we simply add the element context in the list of sources
when computing the evaluation context (the element context is the
context given to the view, which is the way an action give a context to
a view)
In short, handling context is hard...
If the picking has no carrier set, do not open the put in pack wizard
and keep the behavior of a classic picking. Also, filter the delivery
packages according to the carrier (note: this doesn't work at the moment
because of a bug in the new views, but it'll be fixed very soon, so we
merge anyway).
Also, remove an harmless typo in `manage_package_type` method.
If the option 'event_open_popup' is set to true, then the calendar view will open events (or records) in a FormViewDialog. Otherwise, it will open events in a new form view (with a do_action)
Before this change the t-call can use only receive a literal as parameters:
<t t-call="template.name17" />
This call render the template 'template.name17' with the current context.
Now, we can defined an expression with braces (same syntax that t-attf):
<t t-call="template.name{{ 10 + 7 }}" />
This call render the template 'template.name17' with the current context.
This change allows for greater flexibility for applications using qweb.
(The performance due to this change is unchanged during rendering time.)
These commit are the 3rd part of improvements
of Services flows.
It introduces 2 important parts
- timesheet revenue: how much the timesheet bring back
money.
- timesheet overview: a kind of dashboad to see the financial
state of a project, grouped by employee or billable type
Other improvements are UX, adding missing settings, hide
some technical fields, ... to ease the configuration and
day-to-day usage.
This commits add the timesheet overview on the project
kanban. Instead of redirecting to timesheet list, the user
will see a more detailled view.
The timesheet dashboard shows the amount per billable types,
the numbers of hours provided per employee and per billable
types, ...
This view is integrated with the search view : changing the
filter will shows you the informations for your selection.
The purpose is to give the user a global view of the project
(or other timesheet) financial situation in the same place.
This overview is made to be extended in enterprise to add
a section to compare past (timesheets) and futures (forecasts)
activities.
The purpose is to ease timesheet configuration by
adding missing settings: 'invoicing policy' setting
exists in sale config. This commit duplicate it
into timesheet config.
It also add settings in project, sale and timesheet
to configure more easily the service products (time
and material, and fixed price), by adding filter for
services.
This commit introduces the concept of timesheet
revenue, aka how much the timesheet bring back
money.
If the timesheet is not invoiced yet, the computed
revenue is theorical, based on the billable type
(if your product is Time and Material, or Fixed Price).
The formulae use at the timesheet line creation is
If product on delivered quantity:
timesheet hours * (SO Line Price) * (1- discount),
elif product on ordered quantities & create task:
min (
timesheet hours * (SO Line unit price) * (1- discount),
TOTAL SO - TOTAL INVOICED - sum(timesheet
revenues with invoice_id=False)
)
else: (non billable case)
0
When the timesheet is invoiced, the revenue is recomputed
based on the prorata of the invoice amount : prorata of
number of hours for 'time and material' product,
prorata of the theorical revenue for 'fixed price' product.
The timesheet revenue is expressed in the currency of the
company (Monetary field, based on the company_currency_id field
of account.analytic.line) to ease reporting.
This feature normally can handle multi currency (different currency
from SO, INV, and analytic account).
Before this rev., the function that parses monetary fields (i.e.
the one that converts the string value of the input into a
numerical value) totally ignored the sign of the value.
Actually, parsing a monetary field is exactly the same as parsing
a float field, so we simply use the same function.
Unit tests are executed after module installation, which is sometimes
challenging when some part of the UI is modified by another module.
In this case, a test in module web/ was implicitely relying on a behaviour
introduced by the module document.
So, the test failed when document was not installed.
Since the installation of ´document´ module changes the toolbar display,
we check in the test if the module is installed to do the correct assertion.
Before this commit, the parameter ´searchview_hidden´ was not used anymore
when it was defined for some views.
After this commit, the search view is hidden when it needs to be, e.g.
the helpdesk dashboard.
Currently using chatter it is possible to create customers directly when
posting a message. Unknown email addresses are proposed to the user that
can create customers directly in the posting process.
However the record is not updated. Several models like lead, issue, ticket
or event track have a customer (partner_id) field that is not updated even
when a customer is created from the chatter. Users have to update records
manually.
This merge automates it by updating the record through a post process
hook on message_post that is used in main customer-based addons. A small
improvement is done in the chatter to reload the record once posting a
message to a new customer.
When a message is posted through the chatter and creates a new partner
the attendee or track is now updated so that the partner field is correctly
set to the newly-created partner.
Chatter on attendee or track now uses the reload option so that the view is
reloaded after posting a message. The user therefore sees that the record
has been updated accordingly.
When a message is posted through the chatter and creates a new partner
the applicant is now updated so that the partner field is correctly set
to the newly-created partner.
Chatter on applicant now uses the reload option so that the view is
reloaded after posting a message. The user therefore sees that the record
has been updated accordingly.
When a message is posted through the chatter and creates a new partner
the issue is now updated so that the partner field is correctly set to
the newly-created partner.
Chatter on issue now uses the reload option so that the view is reloaded
after posting a message. The user therefore sees that the record has been
updated accordingly.
When a message is posted through the chatter and creates a new partner
the lead / opportunity is now updated so that the partner field is
correctly set to the newly-created partner.
Chatter on lead / opportunity now uses the reload option so that the
view is reloaded after posting a message. The user therefore sees that
the record has been updated accordingly.
Purpose is to be able to reload the view after posting a
message using the chatter. Reason behind that move is that
records can be updated after processing message_post and
this is the easiest solution to enable the reload feature
without having an event-based chatter.
Models inheriting from mail.thread can override this method and hook
on post message_post event and perform some action depending on the
business flow.
Future commits will use that hook to update the record after posting
a message, like updating the customer.
Somewhere in the new views refactoring, between file splitting and rpc
engine quadruple refactoring, a deferred was lost. Due to this chatter
does not have correct information about message recipients.
This commit fixes it by putting the deferred back.
There is currently no 'followed task' filter. Making custom filter does
not work as it erases existing search. When working in some projet context
you do not want to loose your existing search criterions. We therefore
choose to add a new 'my followed task' filter.
We could have made ir.filters not exclusive aka add them to existing
search criterions but "some people" did not want.
Last but not least, we add this filter because FGI requested it.
It seems sufficien to me.
The editable list view may be really new, but it still suffers from a
performance issue. The problem is that we need to evaluate modifiers
for a (sometimes) large number of fields: a list view with 80 rows and 7
columns has 560 field values. This is not so large, but each of these
evaluation is still costly.
In particular, it needs to compute the evaluation context. However, the
evaluation context is the same between all fields of the same record, so
in that case, the web framework does way too much work (with 7 columns,
it is 7 times too much).
This commit does not totally fix the issue, but it helps quite a lot.
What we do is just memoize the evalcontext computation. This means that
it will be evaluated only the first time it is needed, then will be kept
in memory.
Note that this is a fix, not an imp. The list view should be fast...
When a record is added in an x2many field with an onchange, the
onchange is only triggered once the new record is valid (i.e. when
all its required fields have a correct value).
However, there was an issue in the code checking the validity of
a record, as it checked, for each required field, that its value
wasn't falsy (!value). This is incorrect for several type of
fields:
- numerical: a value of 0 is correct
- boolean: should be always considered as correct
- x2m: their value is a dataPoint, so it is never falsy, what
should be check is the number of records inside the dataPoint.
This was an issue for example in the sale.order form view, as the
onchange wasn't triggered when an order line was added (with a set
product), so the total amount wasn't updated correctly.
Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).
This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
in x_layout.less and x.less was a mistake. Many rules can be
considered to be layout and not layout at the same time, developers
always have to switch from one file part to the other, many CSS
selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
fields.less file. As before, the fields_extra.less will contain the
rules specific to community so that the enterprise repo can override
those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
many classes can now be applied outside of form view. These classes
should not be used in templates anyway.
The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).
Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.
The editable list view should also completely stop flickering on chrome
and firefox.
The commit also removes the orange outline on list view dirty cells.
The commit also removes deprecated static xml, LESS and other code.
Notice there are still styles to restore/fix and LESS to improve.
One could set the attribute `default_order` in the view arch
(like 'name,id desc'). The records should then be sorted accordingly.
This feature was not implemented in the new views.
This attribute should work on both basic views and embedded views (x2many).
The former uses the `sort` argument in `search_read` while the latter is
sorted client-side.
There is however a potential issue with the latter: as the order is done
client-side with records received by the server, if there are more records
than the limit, the server will send records without any order. The client
side order will thus be done on a fraction of the records.
This attribute is used to determine one can create a new column in
the kanban view.
Before this commit, it was always true and not specified in the
controller `activeActions` (which was causing a bug where the
no content helper was displayed instead of the column quick create).
The controller was also always initiated with false so the column was
only available after an update.
The third argument of kanban_image should be the id of the record and not the
image `raw_value`.
In this case, we want to display the image field of the current model.
The commit e07f27d has wrongly changed the fallback for one2many raw_value from
an empty array to `false`. This modification brokes a lot of templates where we
assume that the value is always an array.
This commit restores the previous behavior with the fallback on [].
The template `wizard_checkout` uses the `website_sale_order` to render the checkout process pages
But this values isn't passed to the template on these staps:
- /shop/checkout/
- /shop/address/
Purpose
=======
Address management is not clear. If you use the eCommerce, you can set 2 different addresses (billing / shipping) in the checkout process while the related access right group is not activated (group_sale_delivery_address). So you don't see such dates in the backend, which leads to potential conflicts with customer (if the delivery address is different).
Functional spec
===============
- Hide shipping stuff in checkout if option is not activated:
- When eCommerce is installed, group_sale_delivery_address should be activated automatically.
- If you uncheck it from user access (already it is disable in sale settings) , it has to disappear in both the bakend AND the frontend.
With this commit, we try to improve the way navigation is done in the
list view. In particular, we want to make sure that pressing TAB on the
last editable cell move the cursor to the next line (and create a new
line if necessary).
Also, we add a few tests for keyboard navigation (it was almost not
tested before this commit, and while working on this commit, it was
broken at some point).
Graph tooltips (found in accounts and sale/crm's dahsboards) are now
rendering a custom template in order to display more relevant and
coherent information about the graph.
Aaron Bohy