`channel_info` can be called on multiple channels especially during
the init_messaging. The current implementation will perform read and
other queries in the loop. This commits aims to refactor `channel_info`
in order to read all informations in database out of the loop.
Computation of members informations is now the same as for `direct_partner`
As a side effect direct partner will have an email adress and members will have
im_status and out_of_office message if the partner is in a
channel of type chat. It would be easier to compute im_status in all case but
this could create performances issues when calling channel info on channel with
hundreds of users.
channel_fetch_preview will make a query in database in any case but seems to work ok
in api multi. We can put it out of the loop.
44ac7903cc fix shouldn't be broken by this refactoring since we are no longer using the many2many to find direct_partners.
The IAP logo is an svg file, and contains a text tags with font
specified in it. It leads to wrong display in some browser and/or
operating systems when the font is not installed.
To avoid this wrong display we changed the text into a path in the svg.
closesodoo/odoo#30995
Task #1908673
Purpose
=======
The "invoice" modal is too complex to use for new users and has a lot of useless options for
the most simple use cases.
The goal here is to remove 2 options of the 'advance_payment_method' field:
* Invoiceable lines
* Invoiceable lines (deduct down payments)
And combine them into a new one: "Standard invoice".
If there are any down payments to deduct, another checkbox field appears under this
one: "Deduct down payments".
This keeps all the invoicing features while simplifying the modal.
Spec
=======
* Remove "invoiceable lines, deduct down payment" and replace by a checkbox
(checked by default, only visible if down payments to deduct)
* Rename "Invoiceable lines" into "Standard invoice"
* tooltip on radio buttons: A standard invoice is issued with all the order lines ready for invoicing,
according to their invoicing policy (based on ordered quantity or on delivered quantity).
Purpose
=======
The method named "action_invoice_create" in the sale_order model did not make sense:
- this method is not an action (it returns the ids of created invoices)
- it is not used as an action on any xml buttons
- it has no reason to be private
This was probably a "real" action somewhere in the past but now it's just too confusing.
(The method in repair.order was also renamed for the same reasons).
Improve the User Interface of the Calendar mobile view.
- The "today" button should be aligned (both size and position) with the
view switcher icon.
- Extract mobile calendar styling into dedicated SCSS file.
Task ID: 1891955
closesodoo/odoo#30592
Just reflect access rights: publishers should be able to manage channel
members.
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
closesodoo/odoo#30960
To avoid security issues or exploits, public method to add a member on a
channel allows to add only itself, under given restrictions, like being
a channel maintainer to add self on a private channel.
A private method allow to subscribe other people. It will be used notably
to allow publishers to invite other people.
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
This commit changes decorated many2many between slides and participants
recently introduced [1]. It was done between slide and users as people have to
login to have slide information.
Another many2many between channel and partners to store notably completion
and soon add statistics has been added [2]. It has been done between
channels and partners.
In this commit we choose to have the same relationship for slides, aka a link
between slides and partners. It allows to easily compute statistics and find
information based on partner_id.
Co-Authored-By: Quentin Mourrier <qmo@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
[1] See c273e89d55
[2] See 748b9072d6
* portal, web, web_editor
See sub-commits for details.
- Many improvements to the customize dialog 'framework'
(toggle switches, new widgets, ...)
- Optimization of RPCs (including ace editor which shares the same code)
- Move navbar options of the customize menu to the customize dialog
- Add the possibility to control the header logo size
- Add the possibility to control the header font size
task-1904244
closesodoo/odoo#29624
* portal
The user can now choose the font-size of its header menu items through
the customize dialog.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Options and option sets can declare a data-depends attribute to specify
which options need to be enabled for them to be displayed. With this
commit, we allow specifying which options need to be *disabled* for the
same purpose (we can now do that by prefixing the options IDs with '!').
PR https://github.com/odoo/odoo/pull/29624
task-1904244
* web_editor
This commit's goal is to optimize the delay to make a scss customization
thanks to the website customize dialog. Before this commit, the JS code
took advantage of existing web_editor routes but this was far from
efficient as this was done:
1) PY: Load all scss files used in the page
2) JS: Find the one we want to customize and adapt the scss content
3) PY: Create the scss customization with the new content
(So two RPC (including one very slow) and content building in
javascript)
After this commit, this is done:
1) PY: Load the scss file being customized, adapt its content according
to the new values and save the customization
(So the whole logic is in python, requiring only one small RPC)
This commit also take the opportunity to review the web_editor ace
editor loading code (the logic is shared with website customizations).
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Next commit will change that file to make it extend a web_editor model
instead of a web_editor controller. This commit only moves the file.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
* portal, web
This commit introduces the first of many-to-come non-color website user
values: the logo height. Now, the user can choose it in the customize
dialog.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Before this commit, in the theme customize modal, only lists were able
to be visible under the condition of a subset of options being enabled.
Now options can too.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Before this commit, the loading was shown during colorpicker choice or
body image choice too, which makes no sense. This commit also make a new
loading visual which is less intrusive and flicker less.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Before this commit, color options in the theme customize were treated
as big exception in the system. The whole color panel XML was defined
client-side and used custom design. Now, all colors are defined as
options in the "server-side" template, allowing for more customizations
and better maintenance.
This commit also makes the color saving system generic to allow for more
new options in the future (like customizing the logo height or the font
size, which is the next task).
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Move the 'Show Logo', 'Show Sign In' and 'Fixed Top Menu' options from
the customize menu to the customize theme dialog using new features
introduced with https://github.com/odoo/odoo/pull/29624
The customize menu divider is also only added if there are toggable
options in there (which is not the case anymore for all pages since
this commit).
PR https://github.com/odoo/odoo/pull/29624
task-1904244
- Make the controller part more readable and more efficient (O(1) ORM
operations instead of O(n)) and remove deprecated code.
- Add the possibility to have a toggle standalone option. This is
used as soon as an `<opt/>` is alone in its container (note that now,
the container can be any tag and will be ignored during rendering).
- If an option has no specified 'string' to attach to it, the name of
the first view it toggles will be used.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
Since commit 34c47eecd3 wording of link when
sending a quotation by email is broken. Indeed has document in draft is
not correctly considered as having to be signed and/or paid the link is
not labelled correctly.
This commit fixes it. Parameter is also renamed to be more understandable.
This commit is linked to task ID 1910532 and PR #29849 .
closesodoo/odoo#30953
Purpose of this commit is to make a single flow to sign and pay in the
customer portal. When having signed its document popup for payment is
automatically opened.
This is much better for usability and avoid to have orders being signed
and not paid because the customer did not see it was still to be paid.
This commit is related to task ID 1910532 and PR #29849 .
This commit fixes two untranslated terms in the activity view.
From the cohort view, when clicking on a cell to see details, the title was not
translated (missing _t call).
The content was not translated either as the language was not present in the
context.
36d45175b0 was a first step to fix it but while self.record contained data,
self.record.getContext() returns an empty dictionnary (no context is set in the
cohort view).
When computing the context, check that it is not empty, otherwise, fallback on
the session context.
opw-1936855
closesodoo/odoo#30942
journal items does not create Tax Cash Basis Journal Entries.
[IMP] Test Case for Fully reconciling multi-currency lines and one or
more are Exchange Rate Differences which are not creating Tax Cash
Basis Journal Entries if there were any Taxed line.
Main
-
Tax Cash Basis Journal Entry creation shall not be prompted by the
reconciliation of exchange rate difference journal items.
Explanation
-
Company's Currency EUR
Having issued an invoice at date Nov-21-2018 as:
Accounts Amount Currency Debit(EUR) Credit(EUR)
---------------------------------------------------------------------
Expenses 5,301.00 USD 106,841.65 0.00
Taxes 848.16 USD 17,094.66 0.00
Payables -6,149.16 USD 0.00 123,936.31
On Dec-20-2018 user issues an FX Journal Entry as:
Accounts Amount Currency Debit(EUR) Credit(EUR)
---------------------------------------------------------------------
Payables 0.00 USD 167.86 0.00
FX Gains 0.00 USD 0.00 167.86
On Same day user records a payment for:
Accounts Amount Currency Debit(EUR) Credit(EUR)
---------------------------------------------------------------------
Payables 6,149.16 USD 123,768.45 0.00
Bank -6,149.16 USD 0.00 123,768.45
And then reconciles the Payables Items which shall render only one Tax
Cash Basis Journal Entry because of the actual payment, i.e.
amount_currency != 0:
Accounts Amount Currency Debit(EUR) Credit(EUR)
---------------------------------------------------------------------
Tax Base Acc. 0.00 USD 106,841.65 0.00
Tax Base Acc. 0.00 USD 0.00 106,841.65
Creditable Taxes 848.16 USD 17,094.66 0.00
Taxes -848.16 USD 0.00 17,094.66
closesodoo/odoo#30130
Create a new vendor bill.
Choose a vendor with a "supplier currency" different from the company default.
The currency on the vendor bill does not change to the currency of the vendor,
unlike when a purchase order is created.
We set the currency in the partner_id onchange.
opw 1932683
closesodoo/odoo#30961
Try to access a recurring event.
The _search function defined in mail_message tries to read records,
building a list of ids.
They are given to the _search of calendar, which builds its custom SQL query
using the data it received.
Since it got recurring ids instead of real ones, we get:
SELECT id, ("calendar_event"."id" in (101,'101-2019011118000...
Bug introduced in f74f5edc77.
If we get such a request, we convert the virtual ids back to real ids.
Note that a similar conversion was done in calendar's override of "mail.message"
_search method, 'in the case it was asked on virtual ids'.
Note that as of this commit making messages on virtual_ids doesn't even work,
so it is possible that this mess was introduced for the chatter feature,
which has been broken before, and so all of it is useless.
closes#27474closes#28288closes#28621
opw 1928562
opw 1930763
opw 1935148
closesodoo/odoo#30827
When retrieving the BOM lines in `_get_bom_lines`, we check the product
attribute values to know if the BOM line should be taken into account or
not. However, we do not do such a check when we retrieve the price in
`_get_price`.
It can lead to an inconsistency between the sub-lines displayed and the
total price.
We need to apply the same filtering logic when getting the price.
opw-1932437
closesodoo/odoo#30917
Inspired by l10n_multilang
When a theme is installed, the theme.* records are used to generate actual records.
The same was as we use account.account.template to create account.account, the
translations of the theme records should be propagated to the new records.
opw-1918120
closesodoo/odoo#29748
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28900
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28895
Before this commit, when having a calendar notification, the buttons to snooze/cancel
This was because the API of the widget notification changed with 07cd24b1ec
The widget "text" has been changed to "message"
After this commit, the buttons are present and work
OPW 1923132
closesodoo/odoo#30946
In following configuration:
- We have two companies: A and B
- We have a shared product X
- We set a BOM of type KIT for this product X for company B only (the field company on a BOM is mandatory)
- We set no BOM for product X for company A because in company A we sell the product as a regular product
When we sell product X in company A, as a normal stockable product, the invoicing behavior is the same as
when we would sell KIT products. This is because we don't check the SO company when searching the associated
BOM.
closesodoo/odoo#30927
Commit bfb0f1e2a5
did a very good job not seeing that the lines only used move[0],
and called move.field directly.
This could result, for certain BoMs, in traceback.
opw 1928677
closesodoo/odoo#30938
Before this commit, the website menus were created only on write on an event
After this commit, the menus are created at create time too
OPW 1914343
closesodoo/odoo#30919
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28909
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28902
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28901
data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV
This commit is related to task_id : 1909961.
closesodoo/odoo#28899
XavierDo