Turns out %s is not the pattern for sub-minute seconds, that'd be
%S (note the casing). The former is the number of seconds since
epoch, which tends not to match sub-minute second patterns (sounds
like bull to me but there you are), and so importing datetimes was a
bit broken since the previous improvements.
Fix that.
Update the query count to avoid the runbot to be randomly red
Temporary fix!!!!! Will need to check with in details what is the
cause of this.
Those are the changes for the second part of test
In event_sale it is possible to have one product representing several tickets. But before this commit, on the sale order and invoice the client only saw the name of the product and didn't know which event/ticket they subscribed to.
The goal of this commit is to overwrite that behavior whenever a sale order or invoice line is related to an event ticket, to show the ticket name and event name instead of the product name.
Technically, the following changes have been done:
----------------------------------------
* various: add a method to compute a default name for a SaleOrderLine, based on its product
I added the method because the code to compute the name was duplicated in several places. This will make it more consistent.
Moreover this gives the option for modules to override the method to define a custom name as necessary.
----------------------------------------
* event_sale: compute a consistent description for a SaleOrderLine based on an EventTicket
The description will be the same whether the sale order comes from the front end or the back end. It takes into account the customer language.
The default description will be computed as follow:
1. The ticket name should be the first line of the product description on the SO.
2. The event name should be the second line of the product description on the SO.
To compute the ticket multi-line description we decided to ignore entirely the product name and the product description_sale because they are considered to be replaced by the ticket name and event name.
We also ignore them because the work-flow of creating a new event does not lead to filling them correctly, as the product is created through the event interface.
----------------------------------------
* event_sale: improve sale order line and event registration views
It was possible to select a ticket related to a product before an event was selected.
This is typically the case for tickets defined in an event_type but not in an event.
The ticket field is now hidden until both the product and the event have been selected.
This way we are sure the selected ticket will belong to an event and not an event_type.
We reset the ticket on event change because we don't want the user to be able to select a ticket belonging to the wrong event.
We also improve here the comments of the related on-change methods.
----------------------------------------
* website_event_sale: update views to show ticket name and event name
The standard behavior was to show the product name in several places instead of the sale order line description.
However, for event tickets, we don't want to show the product name, but the ticket name and event name instead.
----------------------------------------
* website_event_sale: add ticket on confirmation page
The ticket name was missing from the registration confirmation page (shown when the ticket is free and/or the user paid with a direct method). This is now fixed.
----------------------------------------
Task: 1837987
PR: 25819
- Instead of adding the "timesheet" statbutton on the invoice's
buttonbox, this inherit view is adding a new buttonbox which causes
conflict with the original buttonbox.
This adds a button to import several bills from the accounting dashboard: will create a new vendor bill for each, with the file attached to it. That file will be visible in the chatter (in enterprise) and allow easilly completion/encoding of it. This task also comes along with the import/export of xml files attached to the PDF files created from the invoice report.
Was task 1859277
Was PR #26339
PO that can be linked to an invoice are filtered via a domain
restricting the partner. However when no partner is selected yet, the
domain was `('partner_id', 'child_of', False)` which, beside being horribly slow, was also useless as it returns ALL partners.
Only generate a meaningfull domain.
* Make phantomjs logging clearer by logging within the test case's
module, not odoo.tests.common.
This way, a tour in e.g. point of sale is clearly logged as that,
rather than be logged as odoo.tests.common.phantomjs and require
hunting which module/test we happen to be in.
* Clarify tagging causes for exclusion of selection of tests.
Math.sign(comparisonValue) * comparisonValue being equivalent to
Math.abs(comparisonValue) in all the cases that we consider, we use
the latter formulation that is available in ES5.
Recommended by GitHub's repository alerts.
We normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 9.0 that would be Debian 8
(jessie) and thus Pillow 2.6.1.
However Pillow versions before 3.3.2 and Jinja2 before 2.8.1 suffer
from a few issues that could lead to crashes of Odoo workers.
The bugfixes have been backported in the DEB packages for Pillow,
so users of Debian/Ubuntu LTS versions won't be affected if they are
keeping their systems updated.
However it's worth an exception to our rule for pip users.
Like invoices, a reference is now computed on sales orders.
The configuration of such reference is done through the Wire Transfer acquirer.
The usability of the communication feature (on invoices/SO) has been a bit improved to be more clear.
Was task: 1870121
Was PR #26152
When you need to fast review all properties of a model, mostly the
fields it is really anoying go to all the technical path which has all
the information already.
The previous "View Fields" action was very messy.
My proposal is simply instead use a dialog which is almost useless open
a normal vie (a little improved) which allow us audit completely
everything.
Remove the previous dialog, this will not be used anymore.
Closes#26364
From this rev., the empty value isn't available in the options of
required selection fields, thus preventing the user to unset it.
Related to task #49262Closes#24404
- Create a product A tracked by S/N
- Get some stock of A
- Create a SO and sell 1 unit of A, confirm
- Go to the picking, validate
An error message forces the user to manually encode the 'Done'
quantities.
This step is not necessary, since the user will still get a message
notifying him that the reserved quantities will be used as done
quantities.
opw-1873180
When a subview is defined in a form view, the fields_view_get
extracts it from the global view arch returned. So extending the
field_view_get does not work to change label on subview.
This commit make this work by extending private implementation
instead.
Task #39079
Do not replace the day value without notifying the user.
In undetermined circumstances, a fiscal year last day and month can be
replaced by the default December 31st value. Since all settings are
re-written for any setting changed, this is likely to happen in the back
of the user.
Moreover, the `_verify_fiscalyear_last_day` is not correct since it
doesn't accept February 29th, while `compute_fiscalyear_dates` handles
it.
opw-1867978
opw-1873260
This commit brings a Pie Chart Widget that allows to visualize
simple information on in a single pie chart.
For now it is only used in dashboard view but it could also be
used in another view that uses a basic renderer.
An element with tat widget with attribute name 'pie_chart'
can now be added to the arch view.
Three keys should also be provided in the attribute 'attrs':
- measure (determines the field to aggregate on)
- groupby (determines the field used to group data)
- title (determines the legend of the pie chart)
Task Id: 1835644
A lot of new features have been implemented in search view
but autocompletion was forgotten. This commit fixes many
small problems that were introduced:
- synchronization of facets created through
autocompletion with filters and groupby menus
- filters created through autocompletion can be saved
A previous commit [333ac27] has introduced a new widget TimeRangeMenu
that allows to create two sets of data to compare relatively
to a given date or datetime field.
This commit allows the graph view to render appropriately two
sets of data as would be expected in the different modes.
Task Id: 1835644
A previous commit [333ac27] has introduced a new widget TimeRangeMenu
that allows to create two sets of data to compare relatively
to a given date or datetime field.
This commit allows the pivot view to render appropriately two
sets of data in a unique table. In comparison mode, instead of
one column, three columns are created. One contains the
aggregates from the data of interest, one contains the
aggregates from the comparison data, and the last one contains
information on the data variation (expressed in percentage).
Task Id: 1835644
This commit introduces a new widget 'TimeRangeMenu' used in
the search view. It allows a user to easily:
- search data with a given date or datetime field value
in a specified period of time
- compare the data of interest with data of the previous
period or the previous year.
The time range menu is available in the search view when one
of the four following view types is instantiated:
graph, pivot, cohort, or dashboard.
Task Id: 1835644
The field move_dest_ids is now defined in purchase_stock (since the split at
rev 8d4609a1db)
The line was added in purchase at f6b3247c31 in 11.0 but incorrectly forward
ported.
This commit only moves the code to the appropriate module.
[MOV] move sale_payment into sale
=================================
Almost all use cases of sale require sale_payment down the line.
There is only one case which does not: using sale_management without website_sale or website_quote.
However, since we want to move most of the features of website_quote into sale_management, moving sale_payement first will make the task easier.
[MOV] move website_quote into sale and sale_management
======================================================
We want to use some features of website_quote without having to install the whole module.
The main issue with website_quote was that it had a requirement on website.
What is common to website_sale and sale_management has been moved into sale. This is primarily the sales order portal view.
What is only related to sale_management has been moved into it. This is notably: sales order templates, optional products, sign and pay, ...
Everything that requires website has been moved into a new module named sale_quotation_builder. This is related to using the HTML builder to customize the quotation view.
Models, files and routes have been renamed to better convey their purpose and to follow guidelines more closely.
[IMP] merge sales order portal views
====================================
The old sales order view on the portal has been merged into the one from website_quote. The new view contains features of the two.
A lot of fixes and improvements have also been done, related to BS4 issues but also to improve the sales order view in general.
[IMP] add new settings
======================
The commit adds new settings related to activating the features that previously were activated by installing website_quote.
PR: #26345
Task: 49205, 1838924
The items were hardly readable in the xml because they were in a random order. They are now logically sorted by parent relation and sequence.
Unnecessary groups were also removed (child groups when parents already had more restrictive groups).
PR: #26345
Task: none
The current implementation of odoobot is stateless, making him a little dummy.
Adding a state on the user allow to be sure that the user don't skip a step,
or loop back to a previous step.
States also allows odoobot to repeat the question when the user don't give the
right answer.
A quick modification asked by FP before freeze, in order to change the field
type in time.
It doesn't exists anymore in enterprise version.
Combinaison of website_publish , website_page, and multi website allow to
partially replace it.
AB testing will be back in a later version after a big refactoring.
Christophe Simonis