When a make to order product is sold, a purchase order is created or added to an
existing one. In the second case, the origin of the sale order was lost.
It is now added to the existing source.
opw 656688
The user timezone wasn't respected in the events name.
e.g. for a user with timezone UTC+1,
for an event
from 12/01/2015 00:00:00
to 12/02/2015 00:00:00
The dates in the event name were set to
(2015-11-30 - 2015-12-01)
while it must be
(2015-12-01 - 2015-12-02)
opw-657962
It was impossible to make a partial reconciliation with several lines.
Each time a new line is proposed for the reconciliation, the previous
partial reconcialtion is canceled. The partial reconciliation can just
be proposed on the last selected line when:
self.get("balance") * (last_line.debit - last_line.credit)<0
When a translated term is modified (e.g. content of an email.template),
reloading the translations of the module (e.g. when updating the module) used to
recreate a new, duplicare translation for the modified term (instead of ignoring
the existing one).
This was due to the fact the matching expression (find_expr), when loading
translations, used the field 'src' (source term) as criteria for (almost) all
ir.translation records.
While this is true for type 'code' or 'selection', this is not true for 'model'
where the source content may have been changed.
In case of translation of type 'model', matching on the name and res_id should be
enough for the matching expression and then, avoid creating duplicated
translations.
Note: this patch must NOT be present in 9.0 due to the xml_translate
attribute that splits an xml content into small parts.
opw 654031
When creating missing translations on an object (e.g. using blue flag icon on a
field), the value of the module was not set.
This was problematic as could create a duplicated translation when the module
was updated or the translation reloaded (as the module is used in find_expr).
opw 654036
This revision is related to 93d4db9d1e.
Usually, for models with an image, the original `image` is stored
in the field `image`, and then the resized value are in the fields
`image_medium` & `image_small`.
In the specific case of the product variant, this is not the case,
the original image is stored in the field `image_variant`,
and the `image` field uses as well the method `_get_image_variant`.
The `image_get_resized_images` must therefore return the "big image"
as well, which is returned with the key `image`, by default.
This is done using the method argument `return_big`.
res.users form contains virtual fields in_group_ID to be added in res.groups.
Groups with boolean share=True (added by share module) must not be displayed in
the form and should not be modifiable through the user interface.
However, if a module adding/modifying a res.group is earlier in the dependency
graph than 'share' (e.g. only depends from 'base'), the update of the user view
is done before share is loaded and the overrride of 'get_application_groups' is
never executed.
As we can not guarantee that the module is share loaded, put the logic of
hidding the module in base instead of share.
This workaround is quite hacky but is necessary in stable version.
Better fix in 9.0 at cf63d4d
Fixes#6324Fixes#5820
This is possible to set an image for a specific variant
When this was the case, the image displayed was always the
image within its original size, it wasn't resized
to small and medium sizes.
opw-657055
This revision is related to 5a10903e9b.
The above revision makes so the decimal separator from the language
is used to display the prices.
This revision makes so this decimal separator is used as well
for quantities, to be coherent.
opw-657591
In the pos interface,
when adding a product to the order,
the quantity was set to `1`,
but, when adding the same product again,
the quantity was set to `2.000`.
We use `set_quantity` to not
copy/paste what is already done
in this method to display
correctly the quantity within
the product unit of measure rounding.
This revision is related to 1b8c9aed9f
As `manual` is now the default value of the `state`,
if `state` is not given in the values when passed to
`create` or `write` of `ir.model` and `ir.model.fields`,
we must assume the value is `manual`, so the columns and tables
are instanciated in database
opw-657750
As stated in the comment:
```
all notified_partner_ids of the mail.message
have to be notified for the parented messages
```
Record rules are applied when browsing one2many fields.
Therefore, when browsing `message.notified_partner_ids`
with a user other than the SUPERUSER, the multi-company
rules are applied, and a regular user could therefore not see
all partners of the thread, according to which
company the partners are associated with.
Nevertheless, all partners of the thread have to be notified,
including the ones the regular user cannot see.
To reproduce the issue:
- Create a second company 'Second company'
- Create a third user, associated to the first company 'YourCompany'
- Set the demo user as in the 'Second company'
- Create a project 'test' in the first company, 'YourCompany'
- In the followers of the project, add the Demo user,
with as subtypes "Stages changes" only
- As the third user, create a new task in this project
- Change the stage of this task, as the third user [this is important]
- Sign in as the demo user, and see that you cannot access
your messages inbox, due to an access rights error.
opw-650563
When creating an invoice from a DO,
if there is no analytical account defined on the SO,
then use the default analytical account for that product.
Closes#9725
opw-657492
This was possible to create custom fields `x_*`
but seen as base fields.
For instance,
- Go to Settings > Technical > Database Structure > Fields
- Select a field (any)
- Click on the model link, to be redirected to the model form
- Edit & add a custom field from there.
- Save
- Notice that the field you just added is saved as a base field.
We solve this issue by assuming that all created fields and models
are customs, except the ones created by the ORM, by the database
initialization, the fields coming from the modules in python.
We therefore remove the mechanism on which a field was set
as custom according to the fact `manual` was set to True within
the context: This is now the case by default.
No change was required for the base fields: The `state` `base`
was already forced for those fields, that are created using
direct SQL requests `INSERT INTO`.
opw-657312
Locations were search & read each time you changed
the quantity of a product in a picking.
Once the locations loaded the firs time, this is unlikely
the locations will change during the operation. It shoudln't,
at least.
Therefore, for performances, we avoid to load the locations
each time the picking is reloaded.
opw-648529
Fixes#8344
`categ_sequence` are stored related fields, to `sale_layout_cat_id.sequence`.
Setting a default value for them has as side effect to rewrite
the value on the related field.
To reproduce the issue:
- Create a sale layout category, with 10 as sequence
- Create an invoice with one line, with this sale layout category
- Come back to the sale layout category,
notice that the sequence has been changed to 0.
Besides, as the sequence was rewritten on the sale layout category,
the sequence was rewritten on all sale order lines and invoice lines
having this sale layout category.
If you have a bunch of them, this could take a while.
The `categ_sequence` default value is supposed
to come from the sale layout category.
opw-651937
As atexit function are inherited by subprocess, the pidfile was always
deleted when the first worker (http or cron) died. Now, only the
process that created the pidfile will delete it.
Unsetting the URL of the menu `Home`,
in Settings > Configuration > Website Settings > Configure Website,
leaded to the unavailability of the website.
opw-657572
This applies the commits 503820a and f26b94fd (and their subsequent
corrections) to the calculation of the discount. Indeed, the calculation
of the discount must take into account the corrected price, otherwise
the discount is wrongly computed.
opw-656604
The time_display is present in a translatable email template but was not
translated. Added the missing term.
Updated .pot file for a few missing terms.
Removed base_calendar.pot that has no reason to be in 8.0
Fixes#9573
`stock.move` & `stock.product` have multi-company rules.
There is therefore no reason why `stock.quant` could not have one.
Besides, this could lead to access rights issues,
when a user went to the `Quants` list,
in Warehouse > Traceability > Quants,
while there were quants for products in a company different
than the user company.
opw-653188
Add the possibility in the decorator to specify the `upgrade` and `downgrade`
functions that convert values between APIs. Both function have the same API:
upgrade(self, value, *args, **kwargs)
downgrade(self, value, *args, **kwargs)
The arguments ``self``, ``*args`` and ``**kwargs`` are the ones passed to the
method, following its new-API signature.
Fixes#4944, #7830.
project.task: use an onchange to update date_start when changing user_id.
Indeed date_start is automatically updated in the create / write. Without
the onchange, this may lead to errors related to date_start being greater
then date_end.
project.issue: code in create and write now takes into account date_open
values given to the method and avoid erasing them.
In issue however the onchange is not added. Indeed the date_open and
date_closed fields are not visible in the view. They are automatically
computed and used to compute statistics.
This is a backport of a fix in 9, revision 890f1302c7175e24887e66a2f8b973e72fb4c7e9.
In this revision a context key is added wshen evaluating server actions.
Notification emails created during a server action will be set in the queue
and not send directly.
Some fixes coming from V9 revision 2be1dfc1ed7c9814cd3dbf4eb4cc95f842f738c2. The
purpose is to avoid to send emails in batch and to limitate automatic
subscription.
- add a context key to use the email queue for notifications linked
to allocations created in batch. This way emails will be send asynchronously
and will not create a deadlock when having a lot of allocations to process.
- also fixed a missing context in a browse
The attribute `data-oe-*` (`data-oe-id`, `data-oe-model`, ...)
must not be added when rendering the assets, to avoid
having different assets content,
e.g. a different content for the assets_common,
according if the user is signed in or not,
if the user can edit the website or not.
A different content for an assets according to the
users rights or the user being signed in or not means
that the assets are permanently re-written in the filestore,
which is against the point of the assets.
The content of the assets (assets_common) must not be
different from time to time, it must always be the same
(except when installing a new module, obviously).
Adding the `data-oe` attributes was pointless for the assets
anyway, and prevented having an identical content all
the time, therefore rewritting the assets all the time
in the filestore.
opw-657046
When there is a quote template set on a sale order,
the email sent by default is the email
`Sales Order - Send by Email (Online Quote)`,
and this since 5153b2d281.
Therefore, there is no point to override the content of the
email template `Sales Order - Send by Email` to set
the quotation link in the email template, since this is not
this email which is being used for sales order with an
online quotation template.
Nevertheless, the link to the email quotation must be
put in the `Sales Order - Send by Email (Online Quote)`,
so the customer can access his online quotation directly
from the confirmation email, as it was designed and done
in the override of the `Sales Order - Send by Email`.
opw-657060
`partner_id` is not the `supplier` of the stock move,
this is the destination address:
`Optional address where goods are to be delivered,
specifically used for allotment`.
The supplier would be a related to the `partner_id`
of the `picking_id`.
Nevertheless, displaying the `supplier` in the `stock.move` list
is not useful. You should use the pickign list for that matter.
opw-656985
Closes#9219
When choosing use tasks / use issues, correctly update the project alias. Indeed
only the use issues checkbox had an onchange. This revision adds the onchange
on use tasks so that the method correctly computes the new alias destination model.
Also updated the _get_alias_models method to be more modular instead of hardcoding
values. Call super.
When sharing a survey, a mail.mail is created but the attachment were lost.
This is due to a missing command (6, _, ids) when creating records in
attachment_ids field (many2many).
Fixes#9364, opw 656742
E.R. Spada II
Martin Trigaux
Christophe Matthieu
Denis Ledoux
Goffin Simon
Odoo Translation Bot
Nicolas Lempereur
Invitu
Olivier Dony
Xavier, Sodexis
Christophe Simonis
Nicolas Martinelli
Raphael Collet
qdp-odoo
Thibault Delavallée
Julien Legros
Jairo Llopis
Lionel Sausin
Xavier Morel
Thomas Groutars
Jesús Alan Ramos Rodríguez