When invoicing a product with multiple variants and with anglo_saxon_accounting, the COGS would be the wrong amount.
The function _stock_account_get_anglo_saxon_price_unit() was selecting the first BOM among all variant BOMs.
Using the variant_bom_ids when existing prevent this situation.
OPW-2662863
closesodoo/odoo#78654
X-original-commit: c07d005ae8153745c67527bbf97749e6473e4d41
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: DavidFesquet <DavidFesquet@users.noreply.github.com>
This is a followup on b6c688caa2, which
has introduced a new bug.
Consider two groups A and B in a given category, where B implies A and
also A.id > B.id. For the sake of simplicity, assume that A.id=2 and
B.id=1. Following the commit above, the name of the group selection
field will be 'sel_groups_1_2'.
Consider a user in group B. Because B implies A, this means that the
user now belongs to both A and B. A call to read() on that user returns
field 'sel_groups_1_2' with value 2, which on the form view appears as
the user belonging to A only.
The error is in read(), which assumes that the group ids in the field
name correspond to the implication order of the groups, which is no
longer the case since b6c688caa2.
closesodoo/odoo#78662
X-original-commit: e73c406671a51e9c1c4872a9e85eebe5656ea38e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
On the right panel of the mail editor, the icons of the mass mailing
module do not match with the other icons. We will then update them to
improve the consistency of the layout. The icons will now have the same
background color as the other icons.
task-2658133
Co-Authored-By Carlos Valverde <cvs@odoo.com>
closesodoo/odoo#78645
X-original-commit: 8aa5c39c0ba84a4e5bdb27ff6d70a43ad90ae4af
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Before this commit, it was possible to edit scroll buttons with the
editor toolbar.
task-2656662
closesodoo/odoo#78637
X-original-commit: ca5a36323900a27896761ed12c002d22b6c6cf53
Related: odoo/design-themes#523
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose
=======
Add more fields when we merge multiple leads to be sure not to lose
valuable information.
Specifications
==============
New fields merged
-----------------
Those fields are now propagated to the destination,
- referred
- color
- recurring_revenue
- recurring_plan
- function
- lang_id
- date_deadline
- reveal_id
- lead_mining_request_id
- reveal_ip
- reveal_iap_credits
- reveal_rule_id
- event_lead_rule_id
- event_id
- lost_reason (if the destination lead is lost)
- iap_enrich_done
- tag_ids
The address is taken from the lead with the most non-empty address
fields (sorted by highest rank if multiple leads have the same amount
of non-empty fields).
Followers
---------
When merging multiple leads, we want to move the followers to the
destination lead if they posted a message in the last 30 days.
A message will be added in the merge note to know which followers have
been added.
Views
-----
Remove the "groups" attribute on the recurring revenue
fields. Instead we hide them directly in the views.
Task-2447721
closesodoo/odoo#75742
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Purpose
=======
When merging multiple leads, we want to move the followers to the
destination lead if they posted a message in the last 30 days.
A message will be added in the merge note to know which followers have
been added.
Task-2447721
PR odoo/odoo#75742
Purpose
=======
Add more fields when we merge multiple leads to be sure not lose
valuable information.
Specifications
==============
Those fields are propagated to the destination if the value on the
destination is Falsy
- referred
- color
- recurring_revenue
- recurring_plan
- function
- lang_id
- date_deadline
- reveal_id
- lead_mining_request_id
- reveal_ip
- reveal_iap_credits
- reveal_rule_id
- event_lead_rule_id
- event_id
The "lost_reason" field is propagated to the destination only if it's
lost (otherwise, it makes no sense to have a lost reason on a non-lost
lead).
The field "iap_enrich_done" is set to True if at least one lead has been
enriched.
We also keep the sum of all the lead tags (and remove any potential
duplicates).
The address is taken from the lead with the most non-empty address
fields (sorted by highest rank if multiple lead have the same amount
of non-empty fields).
Task-2447721
PR odoo/odoo#75742
Purpose
=======
This commit remove the "groups" attribute on the recurring revenue
fields. Instead we hide them directly in the views. This group was used
only to turn on / off the feature, not for security reason. So it's
fine to move the group in the views.
It will help for the lead merge so we will not be forced to use SUDO
during the merge.
Task-2447721
PR odoo/odoo#75742
PURPOSE
Light Usability improvements for Reseller module.
SPECIFICATIONS
- Adding some demo data for the menu items Partner Level and Activations to
make sure that user's aren't completely stuck until they find the menu items.
-> Partner Level : Bronze, Silver, Gold
-> Partner Activations : First Contact, Ramp-up, Fully Operational
- Adding action helper for menu items Partner Level and Partner Activations.
-> Partner Level :
Create a Partner Level
Partner Levels allow you to rank up your Partners based on their
performances.
-> Partner Activations :
Create a Partner Activation
Those are used to know where your Partners stand in your onboarding
process.
- Changing name of the menu item "Partner Level" to "Partner Levels".
- Changing Partner Levels and Activation in res.partner form selection to
standard many2one.
- In the partner form changing the location of geolocation to below the groups.
- In kanban view displaying the record to which the partner is assigned, if
there is no assigned partners it will show nothing.
- Change the "Title" label to "Opportunity" in portal, because people think it's
a title as "Doctor" or "Mister".
- In portal while creating new Opportunity the "Opportunity" field will
auto-filled as "contact name's opportunity" when contact name is entered.
- The "opportunities" stat button (res.partner) will show opportunities where
the partner is either customer or assignated partner.
- From crm.lead form letting users to create new Assigned Partner on the fly.
But since the domain requires some basic configs, a new partner won't appear
in the next searches to prevent this, when a new partner is created through
here, we will add it the lowest activation and level possible.
LINKS
PR #67524
Task 2443894
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
- Right now, if you click on 'Geolocate' button on partner form view, and if
partner has no address, it gives no feedback and user doesn't know what
happend.
With this commit, if the geolocating does not work, user will get a toast
notification telling him that 'No address found' to avoid confusion.
- When we click on 'Automatic Assignment' button from crm form view,
if there is no country set on lead, odoo skips the process, but we get the tag
that 'no partner available' which is not correct. It should be
there only when odoo actually tries to find the partner based on
lead's country.
This commit fixes the behavior by showing a toast notification to
user in this case, saying 'There is no country set in address'.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
Currently the 'Opportunities' stat button on partner form view does not show
the opportunities where current partner is assigned one, it only shows the
ones that have current partner(and it's children) set as a customer.
This commit includes such opportunities (where current partner is set as
assigned parter) in the count of stat button and on the view we get when
clicking this button.
taskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
This commit improves the following:
- Hides the icons under the 'Contact' section if the related
information is not available.
- Moves the 'Next Activity Date' next to 'Next Activity' on
opportunity edition dialog, and opens the date-picker to
schedule next activity below the input instead of above it.
- Increased the height of 'Details Next Activity' textarea so
that 'Next Activity Date' picker can be shown within the modal
without introducing scroll-bar.
- This commit renames the label 'Title' to 'Opportunity' to avoid
confusion, and auto-fills it based on the 'Contact Name' for the
modal that is used for creating opportunities from front-end.
Apart from that, this commit also improves string of the button
responsible to create new opportunity from front-end.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
This commit display the assigned parter on kanban view of opportunities next
to the partner (if assigned parter is set). For example, if the customer name
is 'Main Contact' and assigned partner's name is 'Assigned Contact', it will
appear in following format:
Main Contact → Assigned Contact
If there is no customer and only assignd parner, it will look like
→ Assigned Contact
Note that if there is only customer, or no assigned partner and no customer,
nothing changes in the view.
taskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
- This commit removes `selection` widget given on 'Partner Level'
and 'Activation' fields on contact form view to allow users to
create records for them on the fly (with 'no_open' option).
- This commit moves geo-location related fields below the parter assignment
related fields in the 'Partner Assignment' page of contact form view.
- This commit adds default lowest 'Partner Level' and 'Activation' (based on
sequence) while creating assigned partner on the fly from opportunity form
view. The purpose is to allow user to select the created partner again in
'Assigned Partner' m2o, which displays only partners having 'Partner Level'
(grade_id) set.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
- For sake of having basic config for 'Partner Level' and 'Activation'
in contact form view (until user discovers the dedicated menus under
CRM > Configuration > Resellers) in blank db, this commit moves the
demo data related to 'Partner Level' to data, and adds new data for
'Activation', in following sequence:
- Fully-Operation
- Ramp-up
- First Contact
Also, higher ranks for partner level and activation are considered
better, and so the tree views for them now display the records in
the order of their rank (highest on top).
Note that with this commit, we remove 'Platinum' partner level and
it's references that were available in demo data.
- Apart from that in this commit we have also done these changes,
- Renames the menu 'Partner Level' to 'Partner Levels' and adds
action helper for the same.
- Adds action helper for the 'Partner Activations' menu.
TaskID-2443894
closes https://github.com/odoo/odoo/pull/67524
Part-of: odoo/odoo#67524
Steps to follow
- Enable group_show_line_subtotals_tax_included
- Create a repair order and add a tax to a line
-> The subtotal doesn't contain the tax amount
opw-2513287
closesodoo/odoo#78631
X-original-commit: 133888a1859d81a252177b58b046b54d22ba5ca8
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>
Before this commit
Each click event triggered inside a DropdownItem is default prevented
After this commit
Those click events will be default prevented only when the DropdownItem receives a props.href, which will turn it into an <a href/> element.
This corresponds to the initial intention: prevent the default click behavior of an <a href/> element and only keep the DropdownItem click behavior.
opw-2665795
closesodoo/odoo#78628
X-original-commit: 11760db91fc56fb8b998d77661f8d4d7842f3eb8
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Currently markup-ification of the legacy notifications system
display the html content in notification layout for some of the
notification of document and planning from commit: https://github.com/odoo/enterprise/commit/ba44461fea337ed2e5adbdfa1e8eede00b036def
So here in this commit, we make the method `makeLegacyNotificationService`
always `_.escape(message)` and pass `messageIsHtml: true` to the owl
notifications system so notification with html content will be displayed
properly.
Task-2657391
closesodoo/odoo#78627
X-original-commit: 7ce6d8d70be79c9c626865598b898dce9a18b045
Related: odoo/enterprise#21782
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Bug
===
If you send a URL (which will be transformed into a link tracker) to
an external website (e.g. in mass mailing, social, ...), the UTM values
will be added in the GET parameters of the URL.
The external website might crash if those parameters are not supported
by it.
We want to add a system parameter `link_tracker.no_external_tracking`
to be able to not add those UTM values in the redirected URL.
This is done only for external website, because it will never be an
issue if the URL redirect to Odoo.
Task-2657413
closesodoo/odoo#78616
X-original-commit: c8363b7bb74ace4e77b593efc3a9104143240141
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
New users automatically received the Leave Responsible role even though
they were not managing any employees.
closesodoo/odoo#78436
Taskid: 2635715
Signed-off-by: Kevin Baptiste <kba@odoo.com>
It seems that this long dereference causes a MemoryError for accounts
with many associated line_ids
```
select count(*) from account_analytic_account a join account_analytic_line l on l.account_id = a.id join account_move_line ml on ml.id = l.move_id where a.id=7
+---------+
| count |
|---------|
| 131672 |
+---------+
```
The solution we propose is to use search_read inverting the order of
dereferences.
Shortened Traceback:
```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/15.0/addons/purchase/models/analytic_account.py", line 15, in _compute_purchase_order_count
account.purchase_order_count = len(account.line_ids.move_id.purchase_order_id)
...
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 893, in update
field_cache.update(zip(records._ids, values))
MemoryError
```
Observed during the upgrade of 41031
We can reproduce this pref issue locally.
On the menu Accounting > Configuration > Analytic Accounting > Analytic Accounts, with 1 million account moves
```
test_15.0=> select account_id,count(*) from account_analytic_line group by account_id
+--------------+---------+
| account_id | count |
|--------------+---------|
| 1 | 1000002 |
+--------------+---------+
```
We get (shortened):
```
2021-10-19 07:39:33,807 53565 INFO test_15.0 werkzeug: 127.0.0.1 - - [19/Oct/2021 07:39:33] "POST /longpolling/poll HTTP/1.1" 200 - 9 0.077 50.063
2021-10-19 07:39:33,888 53565 INFO test_15.0 werkzeug: 127.0.0.1 - - [19/Oct/2021 07:39:33] "POST /longpolling/im_status HTTP/1.1" 200 - 4 0.038 0.044
2021-10-19 07:40:05,916 53565 WARNING test_15.0 odoo.service.server: Thread <Thread(odoo.service.http.request.140269940897536, started 140269940897536)> virtual real time limit (178/120s) reached.
2021-10-19 07:40:05,921 53565 INFO test_15.0 odoo.service.server: Dumping stacktrace of limit exceeding threads before reloading
2021-10-19 07:40:06,296 53565 INFO test_15.0 odoo.tools.misc:
File: "/usr/lib/python3.8/threading.py", line 890, in _bootstrap
...
File: "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File: "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File: "/home/odoo/src/odoo/15.0/addons/purchase/models/analytic_account.py", line 15, in _compute_purchase_order_count
account.purchase_order_count = len(account.line_ids.move_id.purchase_order_id)
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 2605, in __get__
return self.mapped(records)
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1176, in mapped
self.__get__(first(remaining), type(remaining))
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 2603, in __get__
return super().__get__(records, owner)
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1081, in __get__
recs = record._in_cache_without(self)
File: "/home/odoo/src/odoo/15.0/odoo/models.py", line 5901, in _in_cache_without
return self.browse(ids)
File: "/home/odoo/src/odoo/15.0/odoo/models.py", line 5149, in browse
ids = tuple(ids)
File: "/home/odoo/src/odoo/15.0/odoo/api.py", line 952, in get_missing_ids
if record_id not in field_cache:
```
closesodoo/odoo#78615
X-original-commit: 6077c9358fe650bcdc23e8d6a9432f639fca1b40
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
There was a missing translation for apply/cancel button in
daterangepicker widget. With this change, we provide the odoo
translation to the library when initializing the picker.
opw-2628117
closesodoo/odoo#78588
X-original-commit: 40f128baba53ce29c2d03b7370e54b5010edb9ef
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Warehouse should not be modified when the salesperson is modified
on a confirmed SO
opw-2614063
closesodoo/odoo#78506
X-original-commit: 4b36dc25929b8aeac03b3a93c043b23b89141d94
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jacana <robinengels@users.noreply.github.com>
HR Responsible should be limited to the employee's of the contract's
company.
closesodoo/odoo#78320
Taskid: 2668125
Signed-off-by: Kevin Baptiste <kba@odoo.com>
If a user has access to account.move but not pos.order, it was not
possible to open the invoice or the report
closesodoo/odoo#78579
X-original-commit: 7c84886ebe2fd1aafa5743c7d61bbf0062aa55e1
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
While installing 'website_crm_iap_reveal' module, 'website_crm' module is
auto-installed, and it introduces m2m field 'lead_ids' on visitors. This
field is used within 'website_crm_iap_reveal'.
So, when 'website_crm' is uninstalled, trying to access the field 'lead_ids'
gives a traceback.
This commit fixes this issue by adding 'website_crm' module as a dependency
to 'website_crm_iap_reveal' so that the state remains consistent.
Task-2655439
closesodoo/odoo#78354
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With this commit, we add percentage information in pie chart tooltip,
A pie chart is meant to illustrate numerical proportions.
In Odoo, when hovering a piece of a pie chart, the tooltip is currently not
displayed the proportion/percentage of the piece in the pie. The purpose of
this commit is to provide the user with the percentages of data distribution by
adding them in the tooltip.
In the tooltip displayed when hovering a piece of the pie chart, add the
percentage between brackets.
task-2608695
closesodoo/odoo#78343
X-original-commit: f73bd6dad71045d9f0a012259f148f0c768b964b
Signed-off-by: FrancoisGe <fge@odoo.com>
XML-ID 'chart8111' was set for account 811, which didn't really make
sense. Changed to 'chart811'
Also adapted the translation files accordingly
closesodoo/odoo#78584
X-original-commit: cbf0045f63b4e0e1b4560a7cc8ff4a2a8a6faf86
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When installing the module, the current company didn't receive taxes and fiscal positions, even though the accounts were properly created.
closesodoo/odoo#78568
X-original-commit: 5880192411cb96cd2a14291814bd9991a8761fdd
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Expected Behaviour
When a user reply to a mention (on an invoice, a client profile, ...) in a log_note, and this user answers directly in the chatbox, the answer should be considered as an internal discussion, and so be posted as a log_note.
Observed behaviour
Since V12, when a user reply in the chatbox, the reply is automatically set as a "send-message" reply, which is a issue as the user sends an email to all followers of the discussion while he probably thinks his answer will be visible only by the internal users.
Reproducibility
This bug can be reproduced following these steps:
1. Declare at least 2 users (A and B) and make sure user A handles notifications in Odoo
2. Log as user B, go anywhere in Odoo as user B and mention the user A in a log_note
3. Log as user A, open the mention notification and reply in the chatbox
4. The answer will be noted as a send-message answer, sending then e-mails to all followers ...
Problem Root Cause
As long as the V12 isn't supported anymore, we didn't investigate this version. In V13, the issue comes from the fact the chatbox didn't use the same composer class as the discussion module, and then it's not possible to send a log note from the chatbox. In V14, as the discussion module has been totally refactored, the "error" comes from the arbitrary choice to set "false" as the default value of "isLog" on a general message, which implies that the answer from the chatbox is considered as a "send-message" and not as a "log-note".
Related tickets
opw-2602712
opw-2659484
closesodoo/odoo#78565
X-original-commit: 9e62872561f9914beac8f58f5c3ebed83cd9defc
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The allocation order is not based on the pickings order
To reproduce the issue:
(Need sale_management,mrp)
1. Create a storable product P
2. Create a BoM for another product dummy_P and add 1xP as component
3. Create and confirm a SO with 1x product P
4. Create and confirm a MO for 1x dummy_P
5. Process a receipt transfer with one P
Error: On the SO, the reserved quantity is still 0. The product has been
reserved for the MO, even if the picking of the SO has been created
first
The default order of several SM is based on the sequence and the
identifier:
https://github.com/odoo/odoo/blob/abc9fdaae2927214d98082f391a1dc0fc75e4c77/addons/stock/models/stock_move.py#L26
The default value of the field `sequence` is 10:
https://github.com/odoo/odoo/blob/abc9fdaae2927214d98082f391a1dc0fc75e4c77/addons/stock/models/stock_move.py#L26
When creating a SO, the field isn't defined so its default value is used
(10). However, when creating the MO, the field is defined thanks to the
sequence of the related BOM line:
https://github.com/odoo/odoo/blob/864d90a064f093bd6ba24d8464ee491a443a320e/addons/mrp/models/mrp_production.py#L940
Which, in our case, is equal to 1
As a result, when allocating the quantities in `_action_assign`, the
recordset will contain first the SM of the MO and then the SM of the SO.
This commit ensures the order will be based on the priority, the date
and the identifier (the latter allows the search result to be
deterministic)
Side note: this commit also adds the identifier to the search in
`_run_scheduler_tasks` to keep consistency between the different
flows
OPW-2524205
closesodoo/odoo#78497
X-original-commit: da2b336d467d95cda8ed21707535fb7119f5d777
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
For clarity purpose, tooltips for the 3 accounts in Tax Group (Configuration > Tax Group) are added.
task-2602730
closesodoo/odoo#78453
Related: odoo/enterprise#21725
Signed-off-by: William André (wan) <wan@odoo.com>
Both developments 6c4910a and 7563b44 have been introduced nearly
at the same time in the saas-14.5 version, but the later one is
introducing a side effect that breaks the project sharing feature.
Indeed, before there was one assignee per task (user_id), and now
we can assign several collaborators (user_ids).
As the read on a M2O is just calling the name_get method, it wasn't
an issue.
Now, as it implies to read the res.users (and the res.partner) model,
the assigned users were filtered according to a specific ir.rule
for the portal users:
<record id="res_partner_rule" model="ir.rule">
<field name="name">openerp.portal.res.partner</field>
<field name="model_id" ref="base.model_res_partner"/>
<field name="groups" eval="[(6,0,[ref('group_openerp_portal')])]"/>
<field name="domain_force">[('id','child_of',user.commercial_partner_id.id)]</field>
</record>
This commit creates a new compute non-stored field called
`portal_user_names` to display the name of all assignees in each task in
the project sharing feature. Thus, the portal user can see all assignees
via this char field. The `user_ids` field is removed in the views of
project sharing since the portal cannot see all assignees with this
field.
By doing this, a collaborator cannot edit the field to assign or unassign
himself to a task. To keep this behaviour, two buttons are added in the
form view of task. One called 'Assign To Me', the current collaborator
will be able to assign himself to the task when he will click on this
button. The other button called 'Unassign Me' is to allow the
collaborator to unassign himself to the task.
part of task-2633229
closesodoo/odoo#78538
X-original-commit: 3b5a657df086b54def0bc0bdae89c19c89cb39f5
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Creating lots of production lot can take a huge amount of time if the
mail message follower is added on each chatter.
This commit removes this functionality to speed up the creation as
there is no real need to have the lot creator as follower of it.
closesodoo/odoo#78547
X-original-commit: 9b0e669216948da2710e2e16007f03e47fb7e704
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Searching the stock move line candidate to update at reservation can be
shorten by breaking the loop once one is found
X-original-commit: 93df2568914bee307209e1e739912976c23e1f1d
Part-of: odoo/odoo#78547
The recomputation of stock move state is often done with already
the correct state (for instance in the case of move line deletion only
one of the deletion will change the state).
This commit check the move state before changing it only when it's
necessary.
Task: 2507143
X-original-commit: 80033446a091ff3ba98c58ba44ad665bfba30c98
Part-of: odoo/odoo#78547
Co-authored-by: Remy Voet <ryv@odoo.com>
Current Behaviour :
1. Enable Work Orders
2. Add an operation to a BOM
3. Disable Work Orders
4. Create a manufacturing order for this product and finish the manufacturing.
5. Print the production order
What is the current behavior that you observe?
The production order has the operations in it even though the work order option has been disabled. This is because disabling the work order option just hides the operations and does not remove it from the BOM.
What would be your expected behavior in this case?
The printed production should not show the operation.
opw-2660545
closesodoo/odoo#78544
X-original-commit: d73752c5fe983ce6a9147721e732396394a77cc4
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Issue: When replacing a tracked part while doing a repair, we
are changing the tracking number, but when checking for uniqueness,
we don't take that change into consideration
Steps to reproduce :
1) Manufacture product A with SN "A1" out of product B with SN "B2"
2) Make Repair Order for "A1" to replace "B2" with Product B (SN "B1").
3) Create Manufacturing Order product A (A2), select product B with SN
"B2" as one of the components.
4) Mark as done
-> Bug : "The serial number <B2> used for component <B> has already
been consumed".
Why is that a bug:
When checking for uniqueness we should take into consideration the
parts being replaced
opw-2625687
closesodoo/odoo#78407
X-original-commit: 79c673f9d15185be540dd535d7ebe10c8f138bf1
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
If the denomirator is zero, we set the computed value to zero.
closesodoo/odoo#78522
X-original-commit: 2b0a5ce53aa55da056d6acd6461a56aea75611ce
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit, when dropping custom snippet (or saved snippet)
containing an animation in the page, the animated element of the
snippet remained hidden.
task-2664876
closesodoo/odoo#78493
X-original-commit: 61d7744ca988641bd4d8a4006350ec197eece25a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, every dropdown menu entries in the web editor
had a border-radius on them. It didn't look consistent and clean.
This commit fixes those menu entries by either removing or applying a
correct border-radius.
closesodoo/odoo#78492
X-original-commit: 0239ab7efcaf3895ffb14a56a0686cf5a80bb529
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the CSS of the overlay option buttons of the
timeline snippet was broken.
task-2648348
closesodoo/odoo#78491
X-original-commit: 13770d650def3107378fe4010aac48dc85a5256a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, it was possible to drop an inline snippet (e.g.
badge, cards, etc.) next to a section when this section was a snippet
which can be dropped as main snippets or as inline snippets (e.g.
countdown, embed code, etc.).
task-2648348
closesodoo/odoo#78483
X-original-commit: e2f218fbb3d9bab9dba380582aa93e80fa9becc1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
David (dafr)