Steps to reproduice:
-go to myprofile with hr installed
-go to resume page
-> skills title is duplicated
Reason:
The no_label attribute is set to True but the widget will still display a label.
Expected behavior:
The label should only be displayed once
Fix:
Remove the effectless no_label attribute and remove the separator
closesodoo/odoo#158051
Task: 3815381
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Description:
Add supporting indexes that are used in the queries generated when
openning the accounting dashboard. A query is tweaked to hit
those indexes and avoid `JOIN` where possible.
Benchmark:
Hot loading the default accounting dashboard, default filters and
1 company selected on a staging database with millions of accounting
related entries.
| | Before | After |
|---------|----------|----------|
| Timings | 7.32 sec | 1.6 sec |
Reference:
task-3805835
closesodoo/odoo#157892
Signed-off-by: William André (wan) <wan@odoo.com>
Added a test to verify the behaviour when receiving a negative bill. The
invoice gets imported with negative amounts, but it can't be posted.
When the user tries to post it, they are prompted to turn it into a
credit note with a UserError.
closesodoo/odoo#141485
Signed-off-by: Josse Colpaert <jco@odoo.com>
By default, Bootstrap uses a solid color and dim the element by setting
`$hr-opacity` to `0.25`[1].
Our design comes with a color that is "dimmed by default" since:
```scss
$hr-color ← $border-color ← rgba(currentColor, .25)
```
This commit therefore sets `$hr-opacity: 1 !default`.
At the same time, this also removes the hr background-color that
Bootstrap sets, otherwise it conflicts with the transparent color we are
adding on top of it.
[1]: https://github.com/odoo/odoo/blob/1154556/addons/web/static/lib/bootstrap/scss/_variables.scss#L664closesodoo/odoo#160495
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit fixes a bug where the value of an autocomplete with autoselect
could go into an undefined state where the model value doesn't match the
input value but no change is detected. This would happen on escape press,
scroll and more recently due to https://github.com/odoo/odoo/pull/159333
on click out. To fix this issue, the commit introduces some change in the
autocomplete behavior so that it will no longer select the active option
on click out (blur) when autoselect is active and instead it will revert
the input value to the one stored into the model. Also applies this
behavior on escape key press and scroll for the before mentioned reasons.
Steps to reproduce:
- Go to CRM form view
- Edit the salesperson name to some non existant one and click out (or
scroll or press escape)
Before the fix, the name was stuck to the invalid one but no change was
detected so we couldnt save it. Before https://github.com/odoo/odoo/pull/159333,
click out would select the active option of the dropdown instead (and
launch a dialog for quick create). This is removed because the behavior
is neither intuitive nor practical. After the fix, the name is reset to its
previous valid value instead. This applies to all autocomplete components
with autoselect prop set to true.
closesodoo/odoo#162040
X-original-commit: 9d9026ed0c7bb0af6cf910cc206cf8b55d1b7a36
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Steps to reproduce :
1. click on edit website.
2. click on THEME tab from snippet options.
3. scroll down to input fields.
4. the border width has options for small and large size, which serves
no purpose and were displayed empty.
Purpose:
This commit aims to remove the changes made on [1] which added 2
sublevel options for Border Width for Input Field which served no
purpose.
After this commit :
The Border Width option will not have sub options small and large.
[1]: odoo@388e4bb
task-3771146
closesodoo/odoo#161872
X-original-commit: f35123799408614c0bd50fcb79d147d2f69a84f7
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
In Chrome, if a scroll event is not brand new, its `currentTarget` is
lost.
This commit makes sure that the `currentTarget` of the throttled scroll
event sent to `_onScrollWebsiteAnimate` is kept separately to avoid the
issue in case of throttling delay.
task-3449843
closesodoo/odoo#161850
X-original-commit: 277e9f292a031ed835f4135e597c17dab2fd067d
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
This is a followup on [1].
In Chrome the event's currentTarget is cleared after events such as
"scroll" are handled. For asynchronously called methods to be able to
access it, the current value of currentTarget needs to be kept.
To help developers that might stumble on this issue when using
`throttleForAnimation`, this commit emphasizes the fact that usage of
that function is not limited to event handlers, and it adds a test case
that illustrates a solution for tracking the lost scroll event target.
No scenario was identified in 15.0, but this could be used as an
alternative solution for [1].
[1]: https://github.com/odoo/odoo/commit/0ba601d2ef5c4e2f846818e78dcd23966d6f563d
task-3449843
X-original-commit: 6cc4cbf2b91d624368c489460a90795921985f6b
Part-of: odoo/odoo#161850
Backporting: 1e24b151c6ad0023769b5a561690cb62bcda1d8a
When importing a UBL file, Odoo expects the UBL specific namespaces to
be in the root element of the file. This is not always the case as these
namespaces could exist in every element in the file. When a file is
formatted this way, Odoo cannot extract the necessary data from it
because it is missing the necessary namespaces. To cover this case we
use the lxml.etree.Element.find function instead, and pass in the UBL
specific namespaces to successfully extract the data.
task-3657563
opw-3839398
closesodoo/odoo#161959
X-original-commit: 2845db5966bae3d6f81b6007980053f4ecb00a03
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
When we load a module and the SQL constraints exist both in the table
and in `ir_model_constraint` we need to ensure the xmlid is loaded.
Otherwise the record in `ir_model_constraint` is removed.
Since 4c9968397b we skip returning
existing non-updated constraint records in `_reflect_constraint`. This
leads to them being removed by the ORM. At the end of the load the ORM
sees the record in `ir_model_data` but not in the xmlid pool, thus it
removes it.
closesodoo/odoo#162105
X-original-commit: b5670c7f0d35d13affee2ae93158556346b7dd23
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Bug:
1. Have at least 2 companies ("A" and "B")
2. Export an xml (Bis 3 for instance) for an invoice with customer
"Azure Interior"
3. Set a company on "Azure Interior" (say: A)
4. Import the xml in multicompany mode, with current company = B The
partner "Azure Interior" should be retrieved, but when writing it on the
invoice, it will throw a UserError "odoo.exceptions.UserError:
Incompatible companies on records: 'Draft Invoice (* 63)
(INV/2024/00006)' belongs to company 'B' and 'Partner'
(partner_id: 'Azure Interior') belongs to another company."
Cause:
We try to write a partner on an invoice belonging to another company. It
only occors when we have several companies selected because there is the
global rule `base.res_partner_rule` that will add `('company_id', 'in',
company_ids + [False])` to any search domain on the partner
(`company_ids` is replaced by `env.companies.ids`, see `_eval_context`).
Fix:
Ensure any search domain contains `env.company.id`: the `company_id` of
the move being created.
opw-3829223
closesodoo/odoo#162019
X-original-commit: 18119d446bdca9c04b7085bd1a1bd2f0e0b94ff3
Related: odoo/enterprise#60816
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Commit [1] introduced a fix for old browsers to make the `at` method of
the Array class. It did so by simply adding a property on the prototype
of the Array class.
Unfortunately this way of adding a method means that it is exposed in
`for...in` loops.
To avoid this, this commit uses Object.defineProperty and sets the
property as not enumerable, removing it from the for..in loop.
[1]: https://github.com/odoo/odoo/commit/6e39e31030c28a8eb09ddcd93ca9ca382b4f6f10
opw-3824593
closesodoo/odoo#161891
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- Set warehouse to two-steps reception
- Create a BoM using a MTO (buy) component
- Create a MO for 2 units of that BoM
- Produce 1 and create a backorder
- Open the Overview
Issue:
When there is a backorder (or if the MO is splitted), then when browsing
the dests through `_rollup_move_dests()`, at some point it will branch
into two differents path, related to each backorders. This will raise a
traceback, as we only expected a single MO at that point.
To avoid this, we made the `_rollup_move_dests()` method batchable, so
we can fetch all moves linked to a manufacturing order in a single call,
avoiding this issue.
Note: For consistency sake, updated the `_rollup_move_origs()` method to
be batchable as well, to avoid confusion when using one or the other.
opw-3849252
closesodoo/odoo#161790
X-original-commit: d2830fccbe5dc733673d048303f573bb57a398a6
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce:
1) Set up mondial relay and publish it
2) Go to /shop, add a product and checkout
3) Choose a pickup location of mondial relay
4) Reload the page
5) Observe an error 'You cannot edit the address of a Point Relais'
Reason: a partner was created without
mandatory field 'phone` for the shipping address
Solution: do not check mandatory fields for mondial relay partners
as it is not allowed to edit them
closesodoo/odoo#162047
Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>
The payment method's `support_tokenization` field was incorrectly set to
`False` instead to `True`. This didn't prevent the SEPA Direct Debit
provider from tokenizing this payment method because it always creates
tokens when a payment transaction is confirmed. However, the payment
method was not shown in payment contexts where tokenization is required
(e.g., Subscriptions' portal page, /my/payment_method page).
opw-3756773
closesodoo/odoo#161561
Related: odoo/enterprise#60562
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds slight improvement to the design of remote work
by adding margin to "Set Location" button.
task-3693392
closesodoo/odoo#157502
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
-------------------
[A] Create an automated action with:
- Model: Tasks (project.task)
- Trigger: On save
- When updating: ID (to mimic "on_create" trigger)
- Execute code:
```py
record.message_post(body="This is a message from automated action (fields triggers: ['id'])")
```
[B] Create a server action (contextual action) with:
- Type: execute code
- Model: Tasks (project.task)
- code:
```py
record.write({})
```
[C] Test:
- create a new task --> message has been posted (OK)
- write some values on the task --> no message has been posted (OK)
- run the server action --> message has been posted (KO)
Issue:
------
No message should be posted as the ID field has not been modified.
Cause:
------
`if not self._context.get('old_values')` is considered as `True`
because we have an empty dict.
In fact, when we make a write on a record, old_values will be always a dict.
```py
old_values = {
old_vals.pop('id'): old_vals
for old_vals in (records.read(list(vals)) if vals else [])
}
```
Solution:
---------
Old values are not defined in the context during a create.
We can compare `self._context.get('old_values')` with `None`
to differentiate between creating and writing on records.
opw-3736068
closesodoo/odoo#155832
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to Reproduce :
- Install eCommerce.
- Drag and drop the "Donation" snippet.
- Click on the prices in the snippet.
- Toggle the "Pre-Filled Options" option.
- => There is a traceback.
This bug is due to the fact that since commit [1], all templates have
been added to the OWL app. With OWL, a t-foreach in a template can no
longer loop over a 0 number and causes an error if we try to. This is
what happens here, as toggling off the "Pre-filled Options" option sets
the donationAmounts to 0, which is then used in a loop in the templates.
This commit fixes this by replacing the number by an empty array, so the
loop cannot fail.
[1]: https://github.com/odoo/odoo/commit/4703e4a2efa9213979307e4d3dedeedc61ad0fc3
task-3859207
closesodoo/odoo#161431
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Product domains were not considered when computing the min amount to reach to get a discount. For
example, if you created a discount with a minimum amount of 100 for product "X", the discount
would have been applied, even if the amount for "X" was less than 100, as long as the total amount
of the SO was at least 100.
After this fix, only products that match the domain will be considered when computing the amount
that should be compared to the discount's min amount.
opw-3626345
closesodoo/odoo#155085closesodoo/odoo#162020
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Louis Tinel (loti) <loti@odoo.com>
To reproduce:
- Create 2 lines with the same balance but only one has an analytic_distribution (of 100% on an analytic account).
- Create a transfer of accounts for these
=> The counterpart has a distribution of 100% or no distribution.
Indeed, we simply put the distribution of the last line.
It makes no sense: analytic "balance" is generated and does not reflect the transfer move.
We should make a prorata of the distributions of the lines to transfer.
closesodoo/odoo#161982
X-original-commit: dcfe607d48021902c88b79a571a15559434d1592
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
This commit removes the unnecessary duplicate of the 'o-input' class being present
in the template of the (Multi)RecordSelector components. As the RecordAutocomplete
component uses the Autocomplete component, which already set this classname on its
<input> node, the class was present twice in the DOM.
This could affect the style when trying to write a rule on .o_input since both elements
would get the style.
Now, only the input keep the class, which makes things easier and more predictable.
closesodoo/odoo#161934
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
According to https://www.easytax.co/en/countries/greece
the vat number format for Greece is EL123456783
instead of GR12345670.
We also delete the line for country code `el`
from `_ref_vat` dict as we use `gr` for Greece.
opw-3845662
closesodoo/odoo#161955
X-original-commit: b97c74e43638d685b2af8ede4940f37b6a5cd031
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Issue:
======
The powerbox keep increasing in size when you input.
Steps to reproduce the issue:
=============================
- Install arabic
- Go to notes
- write `/`, you can see the powerbox is a bit smal
- use `down/up`arrows to navigate in the powerbox.
- The powerbox width increase until finally gets to it's intended
position.
Origin of the issue:
====================
Since we are providing that `marginRigh` should be equals to `20` in
`getRangePosition` we will move the powerbox to the left a bit and then
with the style property `max-width=100%` it will increase in size
because the current size is a bit small for it. So at every key pressed
it will increase by 20px until it gets to a point where everything is
set and the `marginRight=20` is finally visible.
Soltuion:
=========
We set min-width as max-content so we can position correctly the
powerbox knowing it's final width.
task-3721794
closesodoo/odoo#161924
X-original-commit: b815447bf239049b37a3705cd014c67e3897ba9c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Steps to reproduce:
- Create a project with a task with a sub-task
- Assign manually the sub-task to the project
- Create a product that creates a project based on this product template
- Create an SO with that product
> A copy of your project template will be created and assigned to the SO
Expected Behavior:
Just as in 16.4, the copy of the subtask created during this process
should be associated with the copy of your project template.
Current Behavior:
The subtask is associated with the original project template.
Cause of the issue/Fix:
Confirming the SO will call the copy method on your project template.
During this call copies of its task and sub-task will be created and
should then be remapped to the correct project/task using by the
`map_tasks` method call:
https://github.com/odoo/odoo/blob/f31174e02157e612650e77ebba3ed1fe54b96776/addons/project/models/project_project.py#L436-L437
This use to do the job correctly in 16.4 because of these lines:
https://github.com/odoo/odoo/blob/ce28edbaae5a9af0a8c6e1f2addf4285ec56e9e1/addons/project/models/project_project.py#L415-L419
However, these were removed by Commit 62e53fa, probably because the new
write method of the "project.project" model introduced by this commit
sometimes relies on the "project_id" of these tasks and this information
should be consistent with the future value of the "project_id" of these
tasks. However, the "project_id" of these tasks should still be remapped
to the copied project at some point and in my opinion this should be
done before the new write method is called, so that this method can be
used correctly.
opw-3823013
closesodoo/odoo#160625
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Rewrite the mapping from xmlid to tax to only take into account
standard taxes from the 'account' module
closesodoo/odoo#161945
X-original-commit: d31f3382453a1d288b732e7cb2aa27b26dcfe645
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit:
* when a user changes 'user_id' to set the same previous 'user_id', the
assign date 'date_open' is updated but it should not as the responsible
did not change;
* when a user changes the salesperson 'user_id' of a crm lead, it triggers
a recompute of 'team_id' that triggers a recompute of 'stage_id' that
updates 'date_last_stage_update' even if the stage does not change, which
happens frequently when changing leads within a given team (new assign,
salesperson on holidays, ...)
* when merging opportunities, 'user_id' can be set on the main opportunity
which triggers a recomputation of both 'date_last_stage_update' and
'date_open' as explained in above points;
Reason:
The 'date_last_stage_update' field depends on 'stage_id' which depends on
'team_id' which depends on 'user_id'. As a result, when 'user_id' changes,
'date_last_stage_update' also updates.
Moreover those fields are implemented using editable stored computed fields
which are triggered everytime a value is given to those fields, even when
the same value is given.
After this commit:
'date_last_stage_update' and 'date_open' will only update when there are
real changes.
Also fix 'date_open' update when lead is converted into an opportunity.
'date_open' is the date when a user is assigned to a lead / opportunity. It
should not be set when converting a lead to an opportunity, as those two
flows are different. Only setting a responsible should update it.
Task-3515225
closesodoo/odoo#161918
Forward-port-of: odoo/odoo#144848
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
date_open should not be set when there is no user_id set. Let us be coherent
so that we can see the effect of assigning users that updates the date_open
field.
Task-3515225
X-original-commit: 3720e5aefd7bf9971d0d7b6fc93fc90c1eeecad3
Part-of: odoo/odoo#161918
'date_open' is the date when a user is assigned to a lead / opportunity. It
should not be set when converting a lead to an opportunity, as those two
flows are different. Only setting a responsible should update it.
Task-3515225
X-original-commit: a3dbe23b83e7aae108ff72737c69c783e059f603
Part-of: odoo/odoo#161918
Before this commit:
* when a user changes 'user_id' to set the same previous 'user_id', the
assign date 'date_open' is updated but it should not as the responsible
did not change;
* when a user changes the salesperson 'user_id' of a crm lead, it triggers
a recompute of 'team_id' that triggers a recompute of 'stage_id' that
updates 'date_last_stage_update' even if the stage does not change, which
happens frequently when changing leads within a given team (new assign,
salesperson on holidays, ...)
* when merging opportunities, 'user_id' can be set on the main opportunity
which triggers a recomputation of both 'date_last_stage_update' and
'date_open' as explained in above points;
Reason:
The 'date_last_stage_update' field depends on 'stage_id' which depends on
'team_id' which depends on 'user_id'. As a result, when 'user_id' changes,
'date_last_stage_update' also updates.
Moreover those fields are implemented using editable stored computed fields
which are triggered everytime a value is given to those fields, even when
the same value is given.
After this commit:
'date_last_stage_update' and 'date_open' will only update when there are
real changes.
Task-3515225
X-original-commit: 8dc18806847e5240dba6f05bdd80d313bf466ebf
Part-of: odoo/odoo#161918
Just to see how it behaves currently, as we are going to fix some unwanted
changes. Notably
* setting user_id to the same value as before should not update the
date_open value;
* setting stage_id to the same value as before should not update the
last stage update value;
* triggers generate chain update of those fields (changing team_id
changes user_id that changes date_open, ...);
Task-3515225
X-original-commit: a1c72fff151524f636fae3f253d33b8228d0add9
Part-of: odoo/odoo#161918
While in practice you would never get this inverse
called with more than one record at a time, it is
still wrong to get the company of self in the loop.
Fixing it to keep good conscience :)
closesodoo/odoo#161979
X-original-commit: 56fe4f71f0cca2ca11624bd267e1dec4de2ac929
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
`base_vat.view_partner_base_vat_form` creates a new div `vat_vies_container` referenced by other views such as `l10n_mx_edi_stock.mx_partner_operator_form`
All these extension views have the same priority and in this case the later is trying to access the div before it is even created.
We fix this issue by changing the priority of the view that creates the div from 16 to 15.
closesodoo/odoo#161902
X-original-commit: 67e7289296ea12e69cb07864a2974cd5d4e46cf2
Signed-off-by: William André (wan) <wan@odoo.com>
This commit adds a new module to allow delaying the sending of sales
order confirmation emails, thus removing a performance bottleneck in the
order confirmation flow.
This is particularly useful for "flash" sales in which a large number of
event tickets are sold in a very short time span. When the emails are
scheduled to be sent right away, the email rendering that is part of the
payment post-processing keeps the worker busy. When the system parameter
`sale.async_emails` is set to `True`, the email rendering is delegated
to a cron, allowing the payment post-processing to execute much faster.
task-3782827
closesodoo/odoo#157612
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds the database ID to the IAP calls made to generate text.
It permits to prevent abuses of OpenAI calls.
task-3740440
closesodoo/odoo#154615
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
How to reproduce
- Send an email to catchall@exemple.com, random@exemple.com
(Note : random@exemple.com is an email witch does not exist)
--> Issue the email is not bounced
To justify the change, this was actually the behavior a while ago, prior to odoo-dev@68a457e
The intent of that commit was to consider other possible routes, so this commit
doesn't contradict the change.
Task-3714565
closesodoo/odoo#161782
X-original-commit: df0c05afbf81ce41c9b1b4cfe93476d4ca397749
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps:
- Login as "Mitchel Admin"
- Install hr_skills_survey
- Delete all employee except "Mitchel Admin"
- Open "My profile"
- Open "Resume"
- Add a skill
Actual result:
- Error due to missing employee
- default_employee_id is using the current record id so a user id
- default_employee_id is not the correct ID
- Can lead to record not existing error or access error
Expected result:
- No error
- default_employee_id is the correct employee of the user
- Default employee in dialog is "Mitchel Admin"
opw-3852542
closesodoo/odoo#161636
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
- Create a vendor bill with landed costs
- Add section and note lines
- Try posting the bill (ERROR)
Bug:
display lines should be skipped
opw-3715660
closesodoo/odoo#161791
X-original-commit: 3174c4a793f24782d835a15d96376e45b5f333e4
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
Create and print an SO for a customer based in Luxembourg
Expected behavior:
According to Bpost and to the Post of Luxembourg, the zip code should be
displayed before the city name in the address format in Luxembourg.
Current behavior:
The zip code is displayed after the city name.
opw-3791142
closesodoo/odoo#161738
X-original-commit: 83b38fab6cc69d0ed2c6abae34f2b4e76ef8a601
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
In IT localization open tax "0% S (Services)"
Issue: invoice repartition line tax tag is "+02", it should be "+03"
opw-3860109
closesodoo/odoo#161696
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
There is 2 issues with it:
- People that want to use multiple picking type or multiple store after
manufacturing locations. It's not possible since the equals is strict
on the warehouse store after manufacturing picking type.
- The procurement group always use the default manufacture picking type
and ignore the picking type on the manufacture rule that will be use.
This commit checks if the location is a child of the post production in
order to create the procurement group. It would be an issue for people
having multiple step in post prod. But it could be fix by using a subset
of the warehouse post production location.
Check if we have a manufacture rule with the same warehouse in the
current route. It's not perfect but it could give a more accurate result than
today.
closesodoo/odoo#161690
X-original-commit: f82a0f2ea8f3c57bae915520f9e4a25b54b81ce4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue
-----
Reconciliation models are not searchable by specific fields (e.g. name).
Steps
-----
- Open Accounting -> Configuration -> Reconciliation Models.
- Try typing something into search.
- No field are suggested to search on.
Cause
-----
No search fields are defined for `account.reconcile.model`, only filters.
opw-3847744
closesodoo/odoo#161648
X-original-commit: 973ad96c7cf4b37fbdeea463bbf676cfee920975
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Steps to reproduce:
- Change the recruitment access rights of Marc Demo to "Interviewer".
- Go to Recruitment > Applications > All Applications.
- Create a new application and add Marc Demo as follower of the chatter.
- Write and send a message on the chatter.
> Marc Demo will not be notified
Expected behavior:
As discussed the PO of the recruitment module (gmf), since users with
"interviewer" access rights have access to the chatter and since the
sensible informations are now shared via the salary offer model instead
of relying on the chatter of the application model, the followers of the
chatter with "interviewer" access rights should be notified if pinged on
a log note or if a general message is sent.
Cause of the issue:
Since sensitive informations used to pass through the chatter, users
with "interviewer" access rights did not have access to it, and were
removed on purpose from the recipients of the notifications:
https://github.com/odoo/odoo/blob/cd6ed7f9fd2e0654cfb0672d7a9536dca21035cf/addons/hr_recruitment/models/hr_applicant.py#L376-L379
to avoid any leak of sensible information.
Note:
This access right did not exist before saas-16.4
opw-3783965
closesodoo/odoo#161198
X-original-commit: 6e8795cf5a7d51c4682941a253fb158e8e7e874e
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
An update made to the tremol device has changed the expected content of
the price field. It now expects up to 15 characters in this position,
with a maximum of 5 decimal places.
At present we can send prices with a decimal position greater than 5,
doing so will result in an error from the fiscal device.
This commit adapts the content that gets serialised in order to ensure
that the decimal provided is no longer than 5 decimal places.
closesodoo/odoo#161804
Task-id: none
X-original-commit: 3373ac3a7945d25fee70d114816ce23a16d6e0ef
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Steps to Reproduce :
- install indian Accounting module
- click on invoice
- go to vendor bills
- create new
Issue:
- while creating new and confirming, it will throw a warning message, as this
warning required only for eInvoice only (while confirming the invoice) not for
vendor Bills.
Cause:
- while generating warning message there is no specific condition like that it
is not for vendors
Solution:
- if we gave condition that this warning message is only for out_invoice then
the issue will be solved.
task-3657558
closesodoo/odoo#161333
X-original-commit: 6480dccfea696e759d0ed4225f4edc033adbfc0e
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Flotchet