Before this commit, we had the following issue:
1. Open two tabs A & B.
2. Receive a message from a channel in tab A.
3. Mark it as read in tab A by clicking on the
chat window of the channel.
> The unread counter is correct in tab A: no
unread messages on this channel, and the
messaging menu counter has been updated.
> The unread counter is not correct in tab B:
it still has unread messages on this channel,
and the messaging menu counter has not been
updated.
The issue was caused by not notifying the updated
unread counter to the widgets when receiving the
'channel_seen' notification from the longpoll.
It was working in tab A because this is were we made
the action, so that it already marked messages as
read without waiting for the longpoll response.
However, Tab B has to wait for the longpoll response
to update the unread counter. It was updating the
counter, but it was not notifying the widgets.
This commit fixes the issue by letting the widgets
know when the unread counter has been reset.
Task-ID 1911239
closesodoo/odoo#28833
Fine-tuning of commit: d60f2ab0e2
Which applied when the next action was to create a new activity.
However the problem is also present when the next action is to send an email.
We extract the logic in a new private function to share the code in both cases.
opw 1904156
closesodoo/odoo#28819
On save, the editor will ask to parent widgets if something needs to be
done first. The website navbar will receive that demand and asks to its
action-capable components to do something. For example, the content menu
handles page-related options saving. However, some users with limited
access rights do not have the content menu... but the website navbar
expects that the save action is performed. So, this empty action is
defined here so that all users have an 'on_save' related action.
This was only happening since 12.0 as 'on_save' actions were introduced
there to save page-related options.
closesodoo/odoo#28810
Transfer accounts created for payment acquirers was ignoring the prefix of the main transfer accounts and was always creating accounts with code 000001, 000002, etc.
The reason is because the method was called on an empty recordset
closesodoo/odoo#28789
In a mutli-company account with multiple websites for the
differents companies, the 'contact us' form creates leads in the
company of the admin instead of the one linked to the website.
This PR corrects that behavior by setting a 'company_id' field
to the company_id of the user in case that field is missing on
models that require it.
opw-1907375
closesodoo/odoo#28749
- Create a dynamic product P1 with an optional product P2
- The list price of P2 is 20
- Create a pricelist where P2 is free (fixed price of 0)
- In a SO, choose 'Configure a product' and choose P1, add
In the modal which suggests P2, its price is 20 instead of 0.
This is because we fall back on the list price when fetching the
combination prices.
This should not be necessary since:
- a pricelist is required to fetch a price
- a pricelist should always contain a rule applying to all products
Therefore, the list price doesn't need to be used as a fallback.
It is then necessary to modify the test tours by adding a partner on the
SO before selecting the product. Anyway, this is usually the way to go
since the selection of the partner determines the pricelist.
opw-1902456
closesodoo/odoo#28687
- Install Sales
- Go to Sales > Orders > Customers, 'Invoicing' tab
- Add a Bank Account
The 'External Link' button (which allows opening the form view) on the
bank account is not visible.
More generally, in the case of a One2many list view in a `<group>` tag,
the 'External Link' button of a Many2one field (which allows opening
the form view) is not visible.
The `flex: 1 0 auto;` should not be applied in the list view.
Corresponding PR in v11: #28812
opw-1903158
closesodoo/odoo#28741
In a form view (account.invoice), have a date field as:
<field name="date" options="{\'datepicker\': {\'warn_future\': true}}"/>
Open a record with the field set to a value
Click Edit, click save
Click create
Before this commit, the value of the field of the new record
took the one of the previous record
On account invoices, it resulted on having the popup "The record has been modified etc...."
And it was not possible to create an invoice from another one
this was because we passed the same reference object for the datepicker
After this commit, there is no popup as the field do not take a value from the framework
OPW 1906085
closesodoo/odoo#28759
When a module creates a record from a model M that `_inherits` from some parent
model P, the method `_load_records` creates an XML id for the record, and an
extra XML id for the parent record. The corresponding `ir.model.data` entries
must be created in the right order (parent record, then record), so that the
record is deleted before its parent record.
closesodoo/odoo#28805
Steps to reproduce the bug:
- Let's consider a product P with a BOM in kit
- Create a PO with P and confirm it
- Cancel the shipment and the PO
- Reset to draft the PO and confirm it
- Valide the new shipment and receive P
Bug:
The qty_received was not updated
opw:1904678
Create a coupon/promotion that gives a 100% discount on some digital product.
If the total of the order is 0, then the client won't have the possibility
to download the product(s), since the download links appear on invoiced lines;
and no invoice has been created.
We display the download link on the products if the order total is 0,
as the other cases are already covered by the existing code.
opw 1905682
closesodoo/odoo#28799
By removing the `.id` from the `partner_id.id` domain leaf,
the ORM avoids to do a useless `SELECT` to read
the id of all partners different from the public partner,
as it already got the information from the `sale_order` table
e.g
Here is the SQL request before the revision:
```
SELECT "sale_order".id FROM "sale_order" WHERE ((((("sale_order"."date_order" <= %s) AND ("sale_order"."team_id" in (%s))) AND ("sale_order"."state" = %s)) AND ("sale_order"."partner_id" in (%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s))) AND ("sale_order"."id" in (%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s))) ORDER BY "sale_order"."date_order" DESC,"sale_order"."id" DESC
```
Here it is after:
```
SELECT "sale_order".id FROM "sale_order" WHERE ((((("sale_order"."date_order" <= %s) AND ("sale_order"."team_id" in (%s))) AND ("sale_order"."state" = %s)) AND ("sale_order"."partner_id" != %s)) AND ("sale_order"."id" in (%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s))) ORDER BY "sale_order"."date_order" DESC,"sale_order"."id" DESC
```
closesodoo/odoo#28927
The adaptation to Python 3 was done with two mistakes: the iteration on the lru
cache does not return keys, and functions are not sortable.
closesodoo/odoo#28870
The "sent" field on an invoice indicates if it has been sent to
customer or not.
When the invoice is sent to a customer from a form view the sent was
set, but when it was sent from the "Send" action on the list view,
it was not updated which seems wrong.
opw-1910937
closes#28796
-Ticked by default(Update quantities on SO/PO)
-Hidden in debug mode
-Rename label "To Refund (update SO/PO) into Update quantities on SO/PO"
This commit is related to task ID 1880715 and closes PR #28091.
The purpose of this PR is to allow more flexibility on Manufacturing.
It will allows:
- Pull and Push rules are no more directly trigger. It will require a confirmation from the user in order to launch them. (except when it comes from another rule)
- The user will be able to add extra components. Those components will follow the classic flow (trigger rules, will be present in workorders and produce wizard, ...)
- State will be computed and will not require explicit write
- Advanced filter
Task 1889384
closesodoo/odoo#28034
Before this commit, the placeholder was hardcoded:
'Drag building blocks here'
Now you can customize the placeholder using a data-editor-message attribute.
The purpose is to be able to plan manufacturing order
without propagate the components's documents directly.
Except when the manufacturing comes from a pull rule, it will
be confirmed directly.
In order to do it, it will just create the moves without confirm them.
They will be only confirmed after a 'Mark as Todo' click.
Refactor production order state:
- Directly have an idea of linked workorders's state
- Computed in order to manage it in a single method
- Add tooltips for each state
Remove the None in availability selection field instead use a False
Also refactor the ready_to_produce field in order to only set as
assigned a production order that have the component for its first
workorder.
Historically, the `website_sale.product_attributes` was a customize option.
That template became a normal view (removed customize_show attribute) with
bbd2d0e42
As it is now a normal view, there is no reason left to be an xpath view and we
can move itw code directly into the inherited template.
That way, we can simplify the `website_sale_comparison.product_attributes_body`
template that was doing a cross xpath (inheriting `website_sale.product` but
xpathing a DOM element from `website_sale.product_attributes` which was also
inheriting `website_sale.product`).
Note that cross xpath was not working well with multi website but was fixed
with 410c07283b
Still, we should avoid doing cross xpath when possible (originally it was not
possible since the view was a customize_show) as it is hard to grep DOM element
to find possible breaking xpath when doing changes on DOM.
This is the reason of this commit.
closesodoo/odoo#29044
We restrict the case of locations that can be scrap locations to
locations of usage internal or inventory loss, depending on how you want
to manage your scrap. Other usage of location shouldn't be scrap
locations.
TASK-ID: 38469
When a location is archived, we are checking that it is not used a
warehouse stock or view location to avoid bad configration leading to
inconsistencies on stock available quantities.
TASK-ID: 38469
As configuring multiple vendor locations is a quite advanced case, that
need too change configuration on partners, and eventually routing, we
remove those demo data that can lead to misunderstanding the way vendor
locations works.
We've also adapted a test that was using those demo data
TASK-ID: 38469
The field partner_id on locations is not used in odoo, and can create
some confusion in odoo with the customer/supplier location you can set
on your partner and/or the owner_id you can set on your moves ans
quants. So we removed it.
TASK-ID: 38469
The stock location usage 'procurement' is not used anymore in stock, and
we remove it as it is not used either for the stock and valuation of
stock.
TASK-ID: 38469
Purpose : When we create order point in another company, it is not setting name ( sequence ).
After this commit it will use ( sequence ) in all company, as we not set company_id on the sequence of order point.
Task #1908526Closes#28597
In this commit use the python constraint to check the accounts if they are duplicate.
This change is because before this configuration there will be an entry cancelling another one in the same account,
resulting in a not impacted valuation account.
This commit is related to task #1908065.
closesodoo/odoo#28604
The sales tab is displayed on product form even if there are no modules
that need it are installed and no fields are displayed in it.
It has been introduced in this commit: https://github.com/odoo/odoo/commit/8e40fed7734793178e4b661a2b28a7f36f8ff626
that we revert and fix by adding an xpath in the point_of_sale module
that display the sales tab when point_of sale_module is installed (even
if sale module is not installed.
Task ID - 1893455
closesodoo/odoo#28176
* survey, website_slides
While not changing their name or their amount, this commit reorganizes
the assets helpers to:
Avoid all file duplicates in different helpers
----------------------------------------------
Before, we had to put some files in different helpers, like our
bootstrap mixin overrides which were in the _assets_utils template and
in the _assets_bootstrap template.
Enforce the use of an helper when using bootstrap
-------------------------------------------------
Bootstrap functions, variables and mixins are now out of the
_assets_bootstrap template, which now only contains bootstrap css rules
and our bootstrap fixes and extensions.
Allow using the correct bootstrap utils in all assets
-----------------------------------------------------
In some assets (especially editor ones), we may want to use bootstrap
variables even though bootstrap is not included in those. This worked
before but using *default* bootstrap variables. Now, our overrides can
be properly included if necessary.
Note: this commit may also be a first step to allow for backend
bootstrap and frontend bootstrap to co-exist.
closesodoo/odoo#28204
Alexandre Kühn