* Remove filter tag
* Use color attribute on the view who add a filter/legend
* Filter is automatically added when 'avatar_field' option is used on a
field tag, and the default template display the avatar.
* Can overwrite the template (add tag template who contains qweb with
<t t-name="calendar-box">...</t>
The new views and widgets (at least some of them) first landed
in web_studio (v10), and they we moved later to web, so changes
in web_studio need to be applied in web.
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
Moving main menu item 'Planning' from mrp_workorder to mrp.
We put this main menu in the module mrp to add items in it in module
mrp_workorder and mrp_mps without adding a dependency of mrp_workorder
to mrp_mps
Currently, if you create a manufacturing order, you can select
all the product that have a BOM. But some product have BOM that
are archived or that can't be manufactured.
This commit add a constraint in the domain for product field.
The constraint ensure that BOM are not archived nor phantom BOM.
The alert box was flickering if empty: at each click on the status
button, the box was appearing and disappearing quickly. This is probably
due to a bug in the form view that do not wait for the evaluation of the
attrs. This bug is fixed in the new views, but only if the attrs is
fixed. Indeed, as the attrs condition is
attrs="{'invisible': [('production_messages', '=', False)]}"
the field was never set to False. This is because the compute method was
doing
workorder.production_messages = "<br/>".join(messages)
So, even if `messages` was empty, production_messages will be set to ''.
In [1]: 'aaa'.join([])
Out[1]: ''
So we fix the condition to set False to the field if the string is
empty.
In [6]: 'aaa'.join([]) or False
Out[6]: False
A 50 px height was hardcoded, so if you have more than 2 or 3 messages
they were displayed outside of the messages box. We remove this
hardcoded height and it looks better.
- Create a product with unique SN, create a BOM for this product
- Create a MO to produce 2 units
- Produce the first unit, create a lot number
- Produce the second unit, use the previously created lot number
Nothing prevents the user to do this. However, the user won't be able to
set the MO as "Done", but it is better to prevent the issue as soon as
possible.
opw-724944
- Create a product with 2 variants
- Create a BOM specific for each variant
- Go in the product variant page
the stat button indicates 2 BOMs instead of one.
opw-725126
- Create a MO, components needed are 1 unit of Prod A and 1 unit of Prod
B.
- Click on "Check Availability"
The button "Unreserve" does not appear unless all components are
available.
opw-724940
When clicking on smart button "Manufacturing" for a variant, the action
"act_product_mrp_production" was called to apply the default filter on
product_id = active_id to select the right mrp.production. But the field
product_id was also called "Raw material" and a wrong domain was applied
each the action was triggered from a variant.
opw:725050
- Create Product A with a BOM which depends on a product with tracking
"By Unique Serial Number" (Product B).
- Create a MO for Product A
- In the "Register lots" wizard, add two lines for "Product B", with the
same serial number.
Nothing prevents the user to do it, even when the inventory is posted.
opw-709888
If `product_move` is an empty browse record
`produce_move.product_id.tracking` is `False`, not `none`,
and therefore
`produce_move.product_id.tracking != 'none'` returns True,
and it therefore asked to provide a lot for no reason.
opw-710748
Currently timezones were not or incorrectly taken into account in resource
computation. Indeed complexity comes from attendances being expressed in
naive timezones valid for all users, whereas dates and leaves are computed
into UTC. Computation should always be done in user timezone so that there
are no overlapping days and all time intervals are correctly computed.
A new timezone field is added on leaves to know in which timezone they
were originally encoded. Indeed putting them in naive user timezone
require its original timezone, not the current user timezone, as those
can be different.
This commit also contains code cleaning in resource to be a bit more
pythonic, simplify method parameters and offer a more simple api to
other modules.
Eventually code field is removed on resource as it is not really necessary
for resources. It is explicitly added on workcenter model who use it.
Old methods are still present since a long time and are deprecated since
saas-3. This compatibility layer adds unnecessary complexity to the module
API. Those methods should now be removed. Some renaming is also performed
to ease resource api understanding, notably to better differentiate
internal methods from other methods.
All addons are updated accordingly.
Currently partners have a boolean field to choose whether to receive
notifications only in their Odoo inbox or to receive them in their inbox
and by email. This leads to several issues :
* if a customer is configured to not receive emails he will not receive
any notification on sales orders, leads, ... This is not clearly
indicated to the salesman and it is not easy to know how to change
that behavior
* if an user chooses to receive emails and does not use its inbox a lot
of notifications stay in Odoo. The user has to manually set them as
done to make them disappear which is redundant.
This commit changes that behavior. From now on customers will always
receive all notifications by email. Indeed Odoo is not a customer oriented
mailbox. Moreover sales orders or discussions on leads send to customers
should always be sent by email as it is the standard communication
mechanism. Users will be able to choose to receive notifications in Odoo
or by email. The choice is no longer inbox or inbox + email, but inbox
or email. Choosing one option or the other one depends on the way the
user wants to work.
Technically the field is moved on the users model and selection keys
are renamed. Notification process is modified
* notified_partner_ids contains as before specified recipients as well
as followers matching the subtype
* customers and users working with emails are notified. During that
process customers notifications are marked as done to be able to
track the email state without having needaction. Users notifications
are currently deleted as we do not track their email state.
The removal of partner field implies changes in various addons that
define partner data with this field set in the values.
As picking types aren't always used in a picking context, and picking
aren't really meanigful for a lot of people, we rename this concept as
"operation type" in views and in the planner.
Commit b2cf955e made the lot_id always required in the
produce wizard of the manufacturing order (without work orders).
It should only be required when the finished product is tracked by lot.
To reproduce:
- Create a product A with the routes Manufacturing & Make to Order
- Create a product B with the routes Make to Order & a custom one "Move
from Shelf 1" (see screenshot for the configuration detail)
- Create a BoM for product A which contains the component product B
- Sell product A in a SO and confirm it
- It creates a delivery order for product A, a manufacturing order for
Product A & B and an internal transfer for product B
- The move for product B from WH/Stock/Shelf 1 to WH/Stock is indeed
linked to the move for product B from WH/Stock to Virtual Location/Production
- Cancel the sales order
- All stock moves are cancelled, except the one related to the internal
transfer (WH/Stock/Shelf 1 to WH/Stock)
When the manufacturing order is canceled, raw material as well as
finished moves are canceled. All procurements with finished moves as
"Destination Move" are canceled as well. However, in this use case, a
procurement has been created for a raw material.
The solution is to cancel procurements for raw materials as well, so it
cancels the internal transfer.
opw-706100
In a MO, change a product in "Consumed Materials" by clicking on "Search
more...". It crashes.
Clicking on "Search more..." triggers the onchange since it empties the
line. Since there is no product on the line anymore, it crashes.
opw-705644
Christophe Matthieu