*: im_livechat, im_support, website_livechat
Improvement on top of this commit: https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
=============
Improvements:
=============
1. New thread models "abstract threads" and "website livechat"
new modeling:
0..1 0..1
AbstractThreadWindow <-----+
|---> Abstract Thread
AbstractMessage <-----+ / \
* * / \
/ \
Thread Website Livechat
/ \
/ \
/ \
Thread With Cache Document Thread
/ | \
/ | \
Mailbox Channel Support Channel
|
|
DM
- Thread is used in the backend, while Website Livechat is used in the frontend.
- The main distinction is that Thread relies on mail_manager, while Website Livechat doesn't.
2. Thread widget has its file renamed (from thread.js to thread_widget.js)
3. Most templates in thread.xml now handles Abstract thread
==========
Bug fixes:
==========
1. [FIX] Mail failures from channels were not grouped together.
2. [FIX] Channel names in the discuss sidebar were displaying their escaped representation.
3. [FIX] Thread was rendered several times when receiving a new message.
=======
Others:
=======
1. Removed unused code.
2. Fixed some classnames and corresponding style.
The style for preview info in the systray were incorrect.
Also, mailbox had the old classname ('o_channel_name'), instead of the new one ('o_thread_name')
When the user creates a channel by providing a name, the name is escaped
in order to avoid XSS attacks. As a result, the logic make use of escaped
string, which may be different from the provided string by the user.
As a result, if we do not unescape the string when necessary, the user may
see the escaped version. For instance, if we creates a channel named 'R&D',
it may display 'R&D' to the user.
This commit plays safe by still keeping the handling of channel names in
their escaped form, but unescape it just before displaying it on the sidebar
of the Discuss app to the user.
Since mailboxes are added after the rpc 'mail/init_message', the translations
are loaded. Therefore it is not necessary to lazily load the translations.
Before this commit, mail failures were correctly grouped in the
systray messaging menu, except for mail failures coming from channels.
This commit fixes grouping for mail failures from channel.
When a new message is received and discuss is not open, any chat thread
containing this message is detached. However, if the thread is already
detached, it should not be detached again.
When we add a new message, it should re-render the thread only once.
The `addMessage` function must handles new messages and updated messages.
Some code for updated messages should not be executed for new messages,
which is what this commit does.
- Cleaning website livechat window so that some behaviour are in website livechat instead.
- More shared code in abstract thread / abstract thread windows, thanks to the
introduction of website_livechat model.
In im_livechat, it now handles a {mail.model.WebsiteLivechat}.
Note that this website livechat model is dumb with messages: it stores messages
just before rendering, because this is im_livechat that handles messages.
This should be improved in the future.
Make use of a website livechat model, so that im_livechat can make use of this model.
This provides an almost similar model for threads in the backend and in the frontend.
As a consequence, im_livechat and website livechat windows have been adapted to handle
a website livechat model.
* = im_livechat, im_support
- thread widget now uses abstract thread in `render` method
- thread models have their `init` parameters changed, so that the parent may be optional
- reworked 'creating a new record...' in chatter in create mode:
> new model CreateModeDocumentThread, which basically is a fake document thread
with a fake message for its rendering in create mode of the chatter
> special rendering method of thread_widget for such case: `renderChatterCreateMode`
- renamed thread methods previously named `getMessages` to `fetchMessages`:
> in order to not conflict with `getMessages`, used for rendering
> now, `getMessages` always get messages that are locally,
while `fetchMessages` may fetch messages.
TODO:
- special thread model for im_livechat (rendering is broken ATM)
The intent of this class was to have all mail model be RPC/service calls out of
the box. This is a bit overkill for just 2 lines per new mail models, which is
why this is not used at all.
Renamed "livechat" model into "website livechat", in order to avoid confusion
with backend livechat.
- `im_livechat.model.LivechatMessage` becomes `im_livechat.model.WebsiteLivechatMessage`
- `im_livechat.LivechatWindow` becomes `im_livechat.WebsiteLivechatWindow`
- `displayEmptyChannel` thread rendering options becomes `displayEmptyThread`
- classname `o_chat_content` becomes `o_thread-window_content`, as it is used
only for thread windows.
- template `mail.EmptyChannel` has been renamed to `mail.widget.Thread.Empty`
The value of the statinfo widget is rendered by the qweb after a t-esc.
Say if the python rounding returned 14.0000000001
(supposed to be a two digits precision number through the magic of floats)
then the statinfo widget would print it as-is.
We now format the value at assignation.
opw 1865426
Up until now, services developed (sms) relied on the get() and
InsufficientCreditError mecanism to create iap_accounts on the fly and
recharge it.
This particular workflow does not work well with automated processes which
is why we modify the function get_credit_url such that it will allow the
client to generate the 'recharge' link manually for better integration
of iap services.
This commit adds a new digest module allowing to send recurrent digests by
email. Those contain a summary of the activity and display various KPIs
allowing to see the activity at a glance. It is also a great tool to improve
user engagement.
First commit adds the digest module holding the base mechanics of digest
implementation as well as first KPIs / tips. Other commits add KPIs and
tips based on the specific extended application.
This merge is related to task ID 30655. Closes PR #18318.
Removed current onboarding mail which was send when module was installed.
It is considered as not necessary now that we have a digest module sending
KPIs and tips by email.
This commit is related to task ID 30655 and PR #18318.
Removed current onboarding mail which was send when module was installed.
It is considered as not necessary now that we have a digest module sending
KPIs and tips by email.
This commit is related to task ID 30655 and PR #18318.
Removed current onboarding mail which was send when module was installed.
It is considered as not necessary now that we have a digest module sending
KPIs and tips by email.
This commit is related to task ID 30655 and PR #18318.
Purpose of this commit is send a tip in digest emails so that people
can configure expense modules later.
This commit is linked to task ID 30655 and PR #18318.
Purpose of this commit is send ecommerce sales details KPIs in digest email.
Those are added in the default digest template.
This commit is linked to task ID 30655 and PR #18318.
Purpose of this commit is to send sales details KPIs in digest email. Those are
added in the default digest template.
This commit is linked to task ID 30655 and PR #18318.
Purpose of commit is to implement KPIs about opened tasks for project
digest emails. Opened tasks are nor archived nor in a final stage. Those
are added in the default digest template.
A tip is added to remind to use the mail gateway.
This commit is linked to task ID 30655 and PR #18318.
Purpose of this commit is to send POS sales details in digest emails. Those
are added in the default digest template.
This commit is linked to task ID 30655 and PR #18318.
Purpose of this commit is to send KPIs about hired colleagues in digest
emails. Those are added in the default digest template.
A tip to remind to use the mail gateway is also added.
This commit is linked to task ID 30655 and PR #18318.
Purpose of this commit is send lead / opportunity creation as well as
won opportunities KPIs in digest emails. Those are added in the default
digest template.
A tip to remind to use the mailgateway is also integrated.
This commit is linked to task ID 30655 and PR #18318.
Purpose of this commit is to add revenue details KPIs in digest emails as well
as in default digest send to all users.
This commit is linked to task ID 30655 and PR #18318.
This commit adds a new digest module allowing to send recurrent digests by
email. Those contain a summary of the activity and display various KPIs
allowing to see the activity at a glance. It is also a great tool to improve
user engagement.
Digest module contain the core implementation of digests emails as well as
first basic KPIs. Future commits will gradually add KPIs in various main
addons.
Digests consist in email templates that have to call some methods on digest
module (compute_kpis, compute_tips, compute_kpis_actions) and render it
accordingly. A default digest is given in data allowing to tune it or to
duplicate and modify it.
Frequency is configurable on the digest; digests can be weekly, monthly or
send every 3 months. New employee users are added to the default widget.
KPIs are computed for each subscribed users so that results match its
groups and related access rights. Default digest therefore work for all users
as displayed results depend on their right without having to define separate
digests just for that purpose.
Implementation is done with Studio in mind. KPIs are computed fields on the
digest model. It means using Studio custom computed fields can be defined
to add customization to the digests, using fields named x_kpi_... .
Digests also holds tips to remind and warn users of features to activate
or configure like mailgateway.
KPIs can be linked to actions so that the section contain a link allowing
to directly jump on a given menu, allowing to directly link reporting
menus for example.
This commit is related Task ID 30655 and PR #18318.
Co-authored-by: Siddharth Gajjar <sga@odoo.com>
Steps to reproduce the issue:
- change the demo user settings -> use Sales: User: All Documents only
- create a stockable product with dropship feature on and a supplier
- connect as the demo user
- create a sales order with this product
- confirm the order
- as the admin user, confirm the purchase order generated through dropship
- connect as the demo user
- open the confirmed SO
- add a line with this product
- save the SO
Bug:
An access rights error was raised.
opw:1866015
Have a product with a partner A as a seller, without any description whatsoever
Do a vendor bill with partner A as the partner.
Add the product onto the lines
Before this commit, the description on the line was "False"
After this commit, we fallback onto the product name if no other reference is set
OPW 1865969
closes#25857
Since 160d6577, the translations must be unique on the source.
When calling insert_missing on a field, the final step is to set the correct
source on every translation to keep them synchronised.
In case the translation looked like:
id | lang | src | type | res_id | name
---------+-------+-----+-------+--------+------------------
42 | fr_FR | KGM | model | 2 | product.uom,name
43 | fr_FR | kg | model | 2 | product.uom,name
The final step will fail as violating the unicity constraint.
Remove duplicated translations before making the update.
It was chosen to keep the latest translation as it should be the most up to
date (e.g. after an import creating duplicated translations).
Add a non-regression test for previous change
opw-1864123
Closes#25787
Make an invoice with a line having a cashbasis tax
Make a payment at a future date compared to the invoice's date
Before this commit, the cashbasis move attempted to post many times
which could lead to errors when posting is forbidden
(in the case of the french localization)
After this commit, the cashbasis move is posted only once
OPW 1865179
closes#25832
Alexandre Kühn