product,point_of_sale: Add a widget handle on the sequence, to be able to order the products
easily for the ecommerce for example. (Move it from the PoS module to the
product module)
For Manufacturing and Repairs, replace the gavel by a wrench. A gavel is a small hammer used by a judge; it is not used in manufacturing. Keep it for when we will have a Law app.
For POS, replace the briefcase by a screen:
For timesheet, replace the calendar by a clock:
For calendar, use the calendar:
For event, use a ticket, it's more generic than a martini glass:
Printing the product label is only available on the variants.
It should be available on the product template too as you may not work
with them.
We took the opportunity to refactor the label report too.
Reading N property fields is as costly as reading each field separately.
Reading them one by one makes more sense performance-wise, as you will only
read the ones you need.
On the font-end view of project.issue, only the messages of type `note` were
display. This excluded the messages recieved via email which makes hard to
understand a conversation (e.g. a customer does not sees his own answers).
Instead, only filter out the notifications (change of states, responsible...)
opw-677426
Using groups when declaring an extension of an asset bundle leads to a
different generated asset bundle according to the user's group. This
is not something we want because a dynamic asset bundle's content
means that it could (and it does) trigger unwanted cache invalidation.
website_event, website_blog, website_forum and website_sale add
functions to `website.contentMenu`. These functions are bound to
server side qweb nodes protected by groups. We can always add the
functions; if a user tries to use the routes he should receive a
traceback because of lack of access rules
website_blog adds a `website_blog.editor` module, but is guarded by
the presence of a node in the DOM. We use the same logic to guard the
module added by website_sale with the `.js_sale` node.
website_gengo is working as expected.
The field sales team is not used on lead when created from website.
We use the UTM (i.e. medium) instead to distinguish where the lead is created from.
Currently on mobile, the livechat window would take all the viewport of
a small screen mobile browser. This combined with the "auto open"
feature can be desorienting: users could have only seen the "hello, how
may I help you ?" window and not know what to do or what is happening.
So this commit remove the "auto open" feature if user is on a too small
device (the user would thus have to click on "Have a Question").
closes#12148
opw-678012
1. Rename "Progress (%)" into "Working Time Recorded"
2. Remove tooltip.
3. It should always indicate the exact percentage :
a. if 2 hours planned and 2 hours consumed = 100%
b. if 2 hours planned and 3 hours consumed= 150%
c. in both cases the progression bar should simply stay full.
4. Consider sub task hours
The bank account linked to a journal cannot be systematicaly deleted
with its journal because this bank account can be linked to several
journals.
opw:676374
When creating a new invoice through the web interface,
a bunch of "default" values are loaded once the partner
chosen, thanks to an onchange on this field,
such as the `account_id`, the fiscal position, etc.
It was not when importing an invoice, making it
more difficult to import an invoice.
In addition, the taxes lines were not computed at all
when importing an invoice with taxes within its
invoice lines, while it should be the case
if the tax lines are not forced during the import.
opw-678155
M2O use the autocomplete lib to display its content. The problem is
that if a result is empty (or only composed of whitespaces), a
divider is displayed in the dropdown.
Commit 1d9f7d279a was fixing this by only displaying non-empty
name results... but it did not work as many models implement the
name_search method the wrong way.
The new solution is to add a default display for record values which
are empty strings, at the right places in the webclient components.
Otherwise it is not visible when set on an instance of the new API.
self is a recordset instead of the model `res.users`
Without this patch a low priviledge user was not able to modify its own value
of `notify_email` through the preference window.
Before this commit, many2many list views in wizards did not
handle the blur event at all, which means that the last edited
line was ignored. This is quite a large bug, but not really
visible in our standard install, because we had no many2many
in wizards.
This commit add naive support for blur events. This is only
intended to help the MRP team. A complete solution would
probably involve moving most of the code in One2ManyListView
to X2ManyListView.
Before this revision, a small function in sale was extended by
sale_timesheet to know when to (or not to) create an analytic
account for a SO.
This was nice, but since it was extended only in this module,
there's no real need for the added complexity (*reading
complexity*)
Christophe Matthieu