When compiling the qweb template, if an error occurs, an error message is
displayed with the corresponding failed node.
This messsage was not always correct because the node is modified in place
during the compilation proccess.
The template is now re-read before displaying the error.
Each qweb widget should now explicitily define a method
`get_available_options` which specifies all options used in the widget
rendering.
The options are a dictionary with the option as key and the option type as
value (e.g. string, integer, array, model, etc.).
This is used by the Studio report editor (to customize widget options) and parsed
in JS.
A new `filter` option has been added to filter fields with an optional function.
A new `order` option has been added to sort displayed fields.
The `followRelations` options have also been extended to take a function.
This change greatly facilitates inheritance and xpath and avoids having
to rewrite each time the entire dictionary of t-options.
e.g.
<span t-esc="5" t-options="{'widget': 'char'}" t-options-widget="'float'" t-options-precision="4"/>
the t-options-xxx overwrite the dict. The rendering became:
<span>5.0000</span>
Before this change, the reports were generated in editable mode for branding
to be applied. The branding is used to cut the report and add on each
selected record for generating the pdf.
Applied branding and editing options takes a useless time and branding
was also applied by widgets even if branding was not requested.
When reading the metadata of a record, ensure the order is consistent.
The retrieval of ir.model.data is now done using an order=id query
Use the ORM to retrieve ir.model.data instead of making an SQL to clean old
code (introduced at b3b22afc68)
Closes#25658
This commit includes various improvements:
* 'Event' menu is moved under 'Reporting' menu and will be visible without debug
mode
* view sequence has been changed to pivot, graph, list, form
* new filters have been added:
- Unconfirmed
- Confirmed
- Attended
- Registration Date
- Event Start Date
- Attended Date
Task 1854339
Warehouse's routes, locations, picking types and
sequences are now generated on create or with a post
init hook for exisiting warehouses before module installation.
Before the init hook, warehouses created before mrp module installation
do not have a specific sequence number for manufacturing and they
shared the same sequence production created in data.
The purpose is to define a better sequence order by default.
Rules's name generation is base on their location and warehouse name.
Since locations order is not always the same than the alphabetical
order, we would rather use the id.
Pickings/MO/SO/PO can be linked. Only the increased quantity is
propagated between documents. However their ordered quantities can
also be decrease or they can be cancel. In this case an activity
is created on impacted documents in order to describe the situation
and inform the user that a manual action is probably require.
Also in order to propagate the increased quantity from a MO, we have
to do important modification in MRP and we want to avoid doing it before a
major release. That's why increased quantity on a MO also work with
activity at the moment.
The purpose is to split up the supply chain in different group.
Currently if a user create a SO with a MTO manufacture product
that use MTO/buy components.
SO cancellation will:
- Cancel all the pickings including pickings between MO and suppliers.
- Log an activity on the MO but not cancel it.
We prefer cancel all transfers between SO and MO when the SO is cancel.
Cancel all the transfers between MO and suppliers when the MO is cancel.
Create a new procurement group when the _run_manufacture method is call
allows to achieve this behavior.
Currently MRP do not handle multi locations for components. In order to
be able to use both feature at the same time, we could:
- Improve mrp in order to handle multiple stock.move.line for a
componenet stock.move
- Add a rule that allow to bring all the good from multiple location to
a single location. (was already possible but it requires some
configuration)
This commit introduce a checkbox on the warehouse in order to
automatically configure all the routes/rules/locations/picking_types,...
necessary to bring all the components to a single location before
running the manufacturing order.
Technically it also refactor some stock_warehouse.py methods in order to
easily override the picking_type, rules and routes creation.
Thank to Hetashree Chauhan <hch@odoo.com> for his help.
task_id: 27785
Purpose
=======
It's way more complicated than the dedicated import mechanism on the dashboard
NB:
There are still no way to hide the import button in a generic way.
This kind of ugly hack has already been done in https://github.com/odoo/enterprise/blob/master/sign/static/src/js/sign_backend.js#L53
This should be removed as soon as such a mechanism arrives.
TaskID: 1861619
BS4 blue-ish grayscale is ok for text, borders and shadows but it's too saturate for main components with solid background (eg. control panel and body bg).
This commit will use a desaturate version of the same colors.
Since uom management has been extract in a separated module, we
can now add the possibility to use it without product.
This commit brings the ability to record the timesheets in
an different UoM than 'Hours'. The user can now set an encoding
UoM for its timesheet on the company. This will display the
timesheet field `unit_amount` with a different widget.
For instance, timesheeting in hours will still use
the traditionnal float_time widget, when timesheeting in 'Days'
will displayed a toggle button with a range of defined possible
values.
The widget used by UoM is customizable on the UoM. The `unit_amount`
field should now be decorated with the 'timesheet_uom' widget.
This one will bind the correct widget (float_time, float_toggle, ...).
If the encoding UoM has no widget associated, the fallback will
be 'float_factor', using the uoM converstion factor.
Everything will still be stored in the database in 'Hours' (the
UoM set on the `project_mode_time_id` field on the company).
For more details, please have a look at the subcommits.
Task #39079Closes#24893
Purpose
=======
Be able to speficy analytic accounts and tags on the account_assets module
that should be set on the generated account move lines.
TaskID: 1868221
Purpose
=======
There's no generic way to display a warning message if the user tries to set
a date in the future.
Specification
=============
Add this new feature on the datepicker (in web module), and use it account. For
example for the invoice date on the invoice/vendor bills form view.
TaskID: 1868221
Purpose
=======
Since the account apocalypse in 9.0, there are no way to filter the accounts
based on their 'internal group'.
Specification
=============
Add a Selection field 'internal_group' on the account.account.type to allow
filtering the accounts. The possible internal groups are the following:
- Equity
- Asset
- Liability
- Income
- Expense
Also, set the value to the account types defined in data.
TaskID: 1868221
Purpose
=======
Instead of adding 'copy' on the code, we could try to increment the code by 10
if possible.
Specification
=============
On an account duplication, if the code represents an Integer and if there are
no other account with the code 'code + 10', then increment the account code
by 10. Otherwise, use the default behavior (adding a 'copy' on the code label).
TaskID: 1868221
Purpose
=======
The current limit is 40, this is a little short to have a clean overview
on the bank statement lines when loading the report.
Specification
=============
Set it to 500 instead.
TaskID: 1868221
We want the UoM name (encoding timesheet) to be
displayed in the label of unit_amount field.
To do so, the field_view_get is extended to change
the label on the field decorated with the `timesheet_uom`
widget, in the view arch
If a string attribute is set on the field, it is prior;
so we only add label if no one is set to avoid breaking
view inheritance.
Task #39079
This commit provides a mecanism to allow user
to log their timesheets using any time UoM
they want. Everything will still be stored
in hours in the database (in the UoM selected
with project_mode_time_id field of the company).
The chosen encoding UoM will provide a widget to
help the encoding (float_toggle for Days,
float_time for Hours, ...). The widget will use
the UoM rate conversion.
Task #39079
Time UoM are almost Master Data for timesheet modules.
Some user remove those before installing timesheet modules, making
it impossible and crashing (as some field required a time UoM to be
set at installation).
Since we don't want to hardcode xmlids of 'Hours' and 'Days' time
UoM, we rather prevent the deletion of such UoM in the system.
The UoM can be desactivate to avoid having plenty of them in system
in use.
Task #39079
As timesheet duration (unit_amount) is already
stored in hours in database, the pivot reporting
view should use the float_time widget, even when
encoding in days.
Task #39079
This commit provides new js widgets for list, kanban and form
views on float field.
1/ 'float_factor' displays the normal float field, but takes a
conversion factor as option. The displays value is the normal
one multiplied by the factor.
You can use the widget like
<field name="my_float_field" widget="float_factor"
option="{'factor': 2}"/>
2/ 'float_toggle' displays a button (in edit mode) looping on a
range of given value at each click. A conversion factor is optional
(default will be 1) to display a converted value, but sent to
non converted one to the server.
You can use the widget like
<field name="my_float" widget="float_toggle"
option="{'range': [0, 0.5, 1], 'factor': 2}"/>
'range' and 'factor' are put in the options.
In simple read mode, the widget display the value as a traditionnal
text (like a normal char field).
This commit provides tests and documentation for those 2 widgets.
Task #39079
For historical reason, project depended on product. Probably to use
UoM. Now, UoM is extracted in 'uom' module, and project does not
use UoM anymore (only with timesheet). Removing the 'product'
dependency requires to make hr_timesheet depending of uom, since
this one really use UoM mecanism.
Task #39079
'project_time_mode_id' is the field used to determined the UoM to
use when logging timesheets. It is not used in project alone, but
in timesheet. Moving it make sense, and does not cause any problems.
For now, no UI allow the end user to change it: it is set with the
Hours UoM (hardcoded).
This is a technical move to prepare the feature that will allow
people timesheeting in Days or Hours.
Task #39079
With this commit, most threads show an indicator when a member is typing
something. e.g.
"Mitchell Stephens is typing..."
Supported threads:
- DM
- (public & private) channels
- Livechat (Website & Backend)
Unsupported threads:
- mailboxes (e.g. 'Inbox')
- document thread (= 'Chatter')
- support channel (with `im_support` module)
Some technical details:
- This is a mix between 'start'/'stop' and 'regular notify' strategies.
- On typing text in composer: notify 'start typing' to all members of
thread.
- On clearing text in composer: notify 'stop typing' to all members of
thread.
- A member can only notify once every 2.5 seconds to the server when he
starts or stops typing something (throttled, buffered notify call).
- On receiving a message from someone that is typing: determine that he is
no longer typing.
- On non-empty and unchanged composer text for 5.0 seconds: automatically
notifies all members of thread that he is no longer typing anything.
(This is like a 'soft / cooperative sender' timeout).
- On non-receiving a typing notification of someone after 60 seconds:
determine that he is not longer typing something (This is like a
'hard / receiver assumption' timeout).
- When some types for more than 50 seconds straight: notify that he is
still typing something (again and again every 50 seconds).
- When two or more people are typing something (Multi-User channels), it
displays at most 2 typing users (ordering rule: longer typers first):
"Mitchell Stephens, Marc Brown and more are typing..."
- Timing summary:
- Usually 2.5 seconds uncertainty.
- Up to 5.0 seconds uncertainty on typer inactivity.
- Up to 60 seconds uncertainty on typer page reload / browser tab
closed / etc.
Future Improvements:
- Detect page reload or browser tab close with loose of longpolling
connection
Task-ID 28188
A document thread is a JS-only entity, which is built from data on
'mail.message' received from the server, or from data of a document.
When we detect a change on the message IDs related to a document thread,
we should update this list on the document thread, so that it knows which
messages haven't be fetched from the server yet.
However, the list of message IDs was not updated on a document thread when
no name could be provided to the document thread, which occurs when there
is no no `display_name` data to determine on the record's name.
In this case, it should update the list of message IDs on this document thread
without altering document name. However, it was neither changing the document
name nor updating the message IDs.
This commit fixes this issue by independently update message IDs and the
document name of a document thread.
Before this commit, this test was failing due to phantomjs assuming that
there could be more messages to display on the screen.
The issues comes from the bad support of flexbox with PhantomJS, and this
test broke when we changed a DIV display with 'flex' instead of 'block'.
For instance, this is the expected values:
thread clientHeight: 960
thread scrollHeight: 1629
message clientHeight: 50
With 30 messages, 50 x 30 = 1500 < 1629 and 960 < 1629, so there are
enough messages loaded with this screen and we are not at the top of
the thread (this is the case when clientHeight = scrollHeight).
However, with phantomJS we have the following values:
thread clientHeight: 944
thread scrollHeight: 944
message clientHeight: 259
As a result, with 30 messages, 50 x 30 = 1500 > 944 (looks like
messages do not vertically collide ?) and 944 = 944 so it assumes
we are at the top of the thread, so it fetches for more messages.
This commit fixes this test by enforcing a special rendering of the
thread for phantomJS.
Unfortunately, we can't simply make the hack on the test only. We
have to make discuss and thread aware of this because they should
adapt their rendering right away
Christophe Matthieu