The res_partner squash has added several information to the res_partner_2
Now the is a purchase order for which he's the supplier. In that case, the
planned date on the purchase order line is influenced by the planned date
of the other purchase orders where this partner is the supplier.
Here we create a new res_partner for this test who has no purchase orders related
In that case, the planned date will always the date planned in the calendar at the
basis, which is 3.
NB : Some tests have been modified.
One assert statement in orderpoint_calendar.yml has been modified,
but the change is legit has no python method has been modified at all
HR settings tab of the employee form view was quite ugly. The inherits were causing
a strange layout. It is now fixed. Some items have been relocalized to ease
the readability of the form view.
Currently each new applicant creates a message on the job. This creates
a lot of noise. The 'New application from ..' messages is therefore
removed. The related subtype is also removed because not used
anymore.
Remove from the list of translatable modules the modules that do not contains
any term and have empty .pot file.
website: remove duplicated terms from .pot
Compute attachments on products and templates. For templates, attachments are the
one from the template and its products. Add a link in the views redirecting
to the attachments. Digital prodcuts effetively have attachments for their
content. Being able to see them quickly is interesting.
Among a lot of views tweakings and cleaning, some changes are listed here.
product
- add currency_id, taken from the company
stock
- procurement request and inveotry adjustement wizards now correctly work
on product and templates with 1 or more variants. With one product the product
field is readonly, with a template and/or a product with variants the
product field is limited to the existing varians.
- valuation and cost method fields on the templates now come from property
fields defined on the template, or from property fields defined on the
product category. It allows to define those fields directly from the
category.Among a lot of views tweakings and cleaning, some changes are listed here.
membership
- details not visible in the default product view. However there is a specific view
to use in (membership / configuration / create member product)
Now using a method for the selection. This method is overriden in
various addons to add specific selection entries instead of
completely hardcoding the values. Indeed this breaks inheritance.
Some views have been updated to try to make the various attributes
more inheritable-friendly.
When scanning multiple serial numbers e.g., the list of pack operations
can become quite long. In order to avoid that, we make it possible
for pack operations to contain multiple lots.
The implementation is done in the way that the links between moves
and pack operations remains the way it was. The important difference
is that on action_done, it will check all the reserved quants and their lots at
once first and only afterwards, it will check the lots one by one to check what
it can reserve.
As the details for the lots for the pack operation became a real object, the wizards related
to the pack operation details are not necessary anymore and were replaced
by a form view of the pack operation.
qdp-odoo