Usability improvement:
- Common view for push and pull rules
- Add an help text in order to describe the rule
- Rules menu
- Warehouse checked by default on route created by a warehouse
- Lower the MTO route sequence in order to take it first.
- Tooltip cleaning
Technical improvement:
The purpose of this task was also to merge stock.location.path(push rule) and
procrement.rule. Those two model were design to execute the same task
but in a different direction. Thus it contains duplicate code.
Task ID 1852969.
*: 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`
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>
Task 32132
Currently, importing image requires either uploading them
one-by-one (after the initial import), scripting that upload, or
converting all images to base64 and putting that in the import
file (leading to a huge unreadable file) before actually doing the
import.
This is problematic for non-technical users, especially when they're
deploying or synchronising e-commerce products.
This change matches URLs in image fields and goes to read the URL &
load that as image data. It performs the read inline which is reactive
but means the imports will be very slow (wallclock) as each URL will
have to be fetched and encoded.
Configuration: via config file only
* import_image_timeout (seconds, default 3), initial connection timeout (not
overall file download)
* import_image_maxbytes (bytes, default 10MB): maximum image size to
download, checked before download (Content-Length) and validated
during (in case Content-Length is missing)
* import_image_regex (str), matches field content as "probably an
image", by default checks that the field value starts with
http|https and ends with an image-type extension (e.g. bmp, png, jpg)
Hard Limits:
* only works on fields actually called "icon", "image", "logo" or
"picture"
* the image can't be more than 42MP (checked after all data is
downloaded)
Hooks:
* _can_import_remote_urls (on res.users) checks whether the current
user is allowed to import via URLs
* _import_image_by_url (on base_import.import) performs the actual
download, could be overridden to store urls to import and
batch/queue the actual imports
Rémi Rahir