Purpose of this commit is to clean a bit channel model. Promoted slide
feature is removed as people can already choose an order for a given
channel. Moreover promoted slide will not be used when having a eLearning
display of a channel.
Image field on channels is added as it is not depending on promoted slide
anymore.
To simplify future additions a search-specific template is removed to
have a unique template to display a channel content. It will ease future
merge.
This commit is linked to task ID 1936153 and PR #30985.
Purpose of this commit is to add some statistics computation on slide.channel
model. We want notably to have a count of views and votes (likes and dislikes)
on channels. Completion is also computed.
Purpose is to be able to search and order channels based on those statistics.
Having stored computed fields for some statistics help achieving that purpose.
Tests are added.
This commit is linked to task ID 1936153 and PR #30985.
Purpose is to be able to filter, search and categorize channels. Notably
with eLearning in mind there will be more channels as a channel will also be
used to hold lessons.
For that purpose we add a model of tag linked to channels. Those tags are
organized by groups in order to be able to display them using a menu or
a small hierarchy of tags. Displaying a tag group as a specific navigation
element is controlled by a specific field.
Those models will be used to display a new and improved home page for
channels / courses.
This commit is linked to task ID 1936153 and PR #30985.
`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
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
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#28898
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#28897
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#28896
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#28894
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#28893
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#28892
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#28890
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#28889