Add the source of the invoice on the invoice lines.
It's an hidden field as it's already present on the invoice but this is a
frequent customization request, adding it as invisible to help them.
Closes#9416, task 21073
Add the message_bounce field on res.partner. This allows bounced emails to increment
the counter and thus to filter / exclude / archive partners whose email is invalid.
Like in CRM, stages in recruitment process are now shared accross jobs.
It is still possible to have stages specific to a job using a job_id
field on the stage.
Various heuristics to find the default stage and stages to display have
been updated accordingly.
This domain forced you to choose an analytic account with the same customer. While useful (you search less), it is quite limiting; the case where you need to register your timesheets on an internal account or the account of another partner are not that rare.
In saas-6 the editor assets were always included.
In 9.0 it was only included depending on groups, but should be available
to be overwritten (for example by website_forum which needs to always
include the editor for message posting).
fixes#9402
After this commit was introduced 4a72a70302 , When you click on validate with invoicing enabled without customer,
the popup for select a customer open and immediately we switch to the receipt screen, that gets rid of popup.
In this commit we print the receipt after invoice process done in backend when validate an order with invoicing enabled so that it's work like before.
Port revision 70287d4 to 9.0
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
The onchange of the project field
removed the default partner loaded of the task
if there was no project set on the task, or if the
project was not associated to a specific partner.
There is no obvious reasons to do so,
and the revision 3fe06da634
introducing the regression doesn't explain why
it has been done. At first sight, there is no reason.
opw-657876
When selling a product with a dropshipping route, the available stock was
checked and a warning got raise if it was the case.
The _check_routing was not working properly as is called in a context of an
onchange and 'self' was the record in the database, not in the browser.
Just use check there is a dropshipping route on the product instead of checking
it on the routes of the sale order line (not reliable info anyway).
Add a todo for master to improve it to change the signature of the method.
opw 657760
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
* blacklist all fields by default
* don't use blacklist in get_authorized_fields which is called to see if
a field can be added to a form, instead only use it afterwards to see
if the field can be written to by the formbuilder. That way
formbuilder can whitelist fields which are actually added to forms
on-demand resulting in a more secure interaction
In noupdate, the opt-in setting is ignored by migrations and breaks the
corresponding feature. If the feature is undesirable, don't install the
module.
Stages are now shared by default between sales team. As the sales flow should
be quite the same whatever the sales team, stages are now shared and not
sales team dependant.
The possibility of customizing the flow by adding stages specific to a sales
team still exist. Stages have a team_id field that can be set in the stage
form, in configuration. However this is not the default behavior. A stage
is either common to all sales team, either specific to only one sales team.
This is why there is no team_ids field anymore, only team_id.
Moreover leads do not use stage anymore. A lead is either alive or archived.
The type field on stages is then removed, as all stages are now used in
opportunities only.
A small hack has been introduced in crm_stage default_get. Indeed when going
from the pipeline, creating a stage with a sales team in context should not
create a stage for the current sales team only. Therefore unless specified
in the context, default_team_id is discarded in the default get context.
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 cf63d4dFixes#6324Fixes#5820
Add a related field to the partner_id of the picking. Note that
partner_id on stock.move is different from partner_id on stock.picking
in case of dropshipping, therefore we need to show both fields.
opw-656298
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
When in testing mode there is no need to compute the default image. Indeed
this information is rarely necessary for testing purpose. For the whole set
of Odoo tests, removing the default image computation in test mode makes
a gain of ~10 minuts of computation.
If a user was in multiple team,
and the salesman of a lead was changed to this user,
the team assigned to the lead might change even
if the user was part of the team already set.
opw-657814
Kinjal Mehta