| Age | Commit message (Collapse) | Author |
|---|
|
This field is a non-sense. By using the same logic, it should be added
to any low level model.
Replace the check by a simple verification of presence of an XMLID.
A more generic opt-in solution should be integrated into ORM.
Partially revert commits 0db0e66e96a8f6b393565da6fbb8dce25ec960b7 and
bbd64c22abc19558c1d83a892fc426bf99a094ce.
See #29257 odoo/enterprise#3550
closes odoo/odoo#31778
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
|
|
|
|
* = base, auth_signup, mail, portal, sale, website, website_sale
Before this commit, sending an object by email would always link to web.base.url
even if the object was created from a specific website.
Now if the object has a website, we use the URL of that website if it is set.
The fallback will always be on the web.base.url.
opw-1921030
PR: #30000
|
|
|
|
Purpose of the task is to improve the usability of activity types and
activity scheduling.
Another purpose is alto to protect some master data activity types by flagging
them and preventing their deletion.
Containing
* make the activity type as master data so deletion will be prevented;
* improve the usability of the activity type;
* prevent the deletion of activity type which are used for automated activity;
* change the usability of activity scheduling modal;
This commit is linked to task ID 1907970 and PR #29257.
|
|
|
|
- Install Invoicing
- Multi company Set up with no common contact book
- Create & validate an invoice with user A in company 1
- Change to company 2 with user A
- Connect with user B in company 1
- Send & Print the invoice
An error is raised on the template rendering because user B cannot read
info from user A.
opw-1928676
closes odoo/odoo#30649
|
|
closes odoo/odoo#30045
|
|
opw-1916935
Before this commit, when a next activity was closed, the message said
that the action was performed by the assigned person.
Now, the message say that the action was performed by the person who
closed the activity.
closes odoo/odoo#29678
|
|
|
|
Do not use the model `_description` field which cannot be translated. Use
the `display_name` of the corresponding model instead.
Moreover, `<t t-esc="'%s' % model_description or 'document'"/>` gives
`'None'`, while `'document'` is expected.
This adds a query to some tests, which is expected since `display_name`
requires information stored in the DB, while `_description` is defined
at the Python level.
opw-1908420
|
|
|
|
This commit introduces the "upload file" activity type
category. For an activity of that time, uploading a file
will mark the activity as done (and maybe create the forced
next activities).
This activity type is seen as a shortcut to upload a file
with a reminder.
Task-1915004
closes odoo/odoo#29861
|
|
|
|
Feedback should be the first part of the message without title
to make it more concise.
If the activity has a note, the note should be displayed
but after the feedback.
We can also remove the field feedback that was not so useful
since it was only written just before unlink. Feedback is now
passed as another parameter to the template.
Task: 1918392
closes odoo/odoo#29605
|
|
As activities are created using the current user there is no need anymore to
have another field to store the activity creator. We can therefore remove
create_user_id and replace its use by the magic create_uid field.
This commit is linked to task ID 1856417 and PR #27619.
|
|
|
|
In a multiple company account, when a parter is doesn't have a
company, the mails he revieved have "Send by using odoo" as footer.
This PR correct that by setting the footer to "Send using odoo" when
there is no company.
opw-1894825
|
|
Some people do not understand the old forgotten langage coming from R'yleh
sub-city of Helk'Yizrk. Let us use standard naming then.
closes odoo/odoo#28196
|
|
|
|
|
|
Purpose
=======
display_name is equal to doing name_get()[0][1]
Replacing name_get()[0][1] by display_name could be good for 2 things:
- Uniformization of the code
- Probable optimization if name_get is used inside a for loop on a recordset (as the values will be prefetched and put in the cache).
TaskID: 1849250
closes odoo/odoo#26341
|
|
The mail template mail_template_channel_send_guidelines should only be used
from send_guidelines action. Anyway, with mail_template on activity
and all demo done to show this mechanic on contacts,
trying to render this one will generate a traceback. This fix
transforms the mail_template to qweb view so that it won't be available in
mail template.
|
|
Reducing the possiblity of enterprise users of locking themselves.
|
|
Flow
====
Have one model field responsible of telling when the sales order has to be signed or paid to avoid inconsistencies.
The general rule is: sign & pay are only used upfront to confirm a sales order. If a sales person starts to modify (confirm) it manually, we don't need those features. Especially at that point pay should be done with invoices.
Modal
=====
For the sign, we want to force refresh the page to update its state, and thus we need to show the confirmation message on the reloaded page.
For sign and pay, we changed a bit the structure of the text in the modal to allow to translate it more easily. Also fixed the payment selection by moving it into the body instead of the footer.
For the reject modal, we want the feedback field to be required, so we can see in the chatter by who and why it has been rejected.
Misc
====
Moved remaining bits of code related to preview/pay/accept/decline from sale_management into sale, where it should have been in the first place.
Sales Order:
- Improved status/contextual alerts.
- Hide discount from small to fix responsive.
PR: #26801
task-1876864
remove sales help
|
|
User 1 simply becomes a technical user (inactive, no password).
|
|
Revision on https://github.com/odoo/odoo/commit/02ec09cb1c3e2d7bc7968f40c18f2208d7f3f498#diff-6d76770b1b7cf716d60a4d76a1555c1d
The commit above mostly renamed 'Client Action' to 'Discuss',
but there were some leftovers.
|
|
Master is going wild. https://github.com/odoo/odoo/commit/b6f7ad3adb23fff1aa888d8315aca8157b555b03 added activity
data but https://github.com/odoo/odoo/commit/83fc5dc03ce92df9b920386f9215cdc5504c3be1 renamed the field.
|
|
Add a data common for all models have the 'decoration'
type set to 'warning' to schedule alert activities.
This can be usefull when activities are generated on
related model changes.
Task #39340
|
|
It was possible to define a delay in days on activity type
to reschedule next activity. It is now possible to specify a unit
(days, weeks, months) and a starting point for the delay
(as before, from the moment when the new activity is scheduled,
but also after the deadline of the previous activity).
We realy need to have all javascript action triggering a done
and schedule next to call the python corresponding method on
activities. A part of the work have been there but some
cleaning could still be done in activity.js.
Task: #1870662
PR: #26272
|
|
[IMP] mail; various CSS issues
|
|
Purpose
=======
- Quickly share the url to someone else (a client, a colleague,...)
- Ensure that the recipient can access at least
the portal view of the shared record.
- Typically used when a client cannot retrieve the mail to access his order.
The share link can be used in this case.
Specifications
==============
For any object inheriting form portal.mixin:
- Add a button SHARE (not visible in edit mode)
- When clicking on this button, a popup opens with :
- A warning message for tasks and projects only (see below)
- the link (like in gmail) that can be copied
- Recipients
- mail composer (with preselected template) ==> see below
- button [Send Link] [Copy Link] Discard
- After sharing document, put internal note like
"Document shared to xyz,...." with template message
- Anyone with the link, even anonymous user (not logged in) can have access
to the document with the access token provided in the url.
Impacted models:
- account.invoice (Community)
- project.project (Community)
- project.task (Community)
- purchase.order (Community)
- sale.order (Community)
- helpdesk.ticket (Enterprise)
Warning messages and access rules:
Allowed :
- SO canceled or draft will be accessible with the link
with access_token
- If the customer account is B2B (signup not enabled), the recipient
will anyway see the document as the user specifically wants the
recipient to see the document.
Restrictions :
- For Project and Task, if the privacy is not public, then, there is a
contradiction between the access_token mechanism
and the privacy of the document.
- A warning message will be displayed in the share wizard to inform the
user if the document cannot be visible by the recipients and to
ask him to set the privacy to 'Visible by following customer'.
The send button will, in that case, be hidden.
- To avoid to block the share for a new project, default privacy value
is now set to 'Visible by followong customer'
Technical implementation
========================
- Move the access_token mechanism (field + methods + mail controller)
to the portal.mixin to be able to use it in a generic way for each object
inheriting the portal.mixin
- Generalise a part of the _*model*_get_page_view_values method
into a single one in portal
- Generalize the _*model*_check_access into the portal controller of the
portal module
- Remove the init_column + default value for the access_token
> old records have an access_token,
> new one won't but it will be generated on demand via the get_access_token
Done for performance reasons
- Add share button into action menu separately. + kanban view context menu
(except for task and project where button not in action menu but 'simple'
button for task and project because other modules already provide action
to send documents by email, which is not the case for project and task.)
- Add a sign_token used to authentify the recipient in the portal view chatter,
if any. The message will be posted as if the user was logged in.
- Set the _get_share_url as private for security reason
- Add a redirect parameter to _get_share_url to get
If false : The direct portal view url
If True : The redirect url (mail/view/?)
- Cleaning up unnecessary code
- Bug fix :
- Before, if user was not logged and record had partner_id,
if partner id was null, post message was done as admin.
Now, the post message is done as public user.
- If the user had an uid but had no access_token, he could be able
to gain the access token of the record.
check_access_rights was missing in the get_access_action.
Task ID : 30985
Closes #25629
|
|
This reverts commit c4af8f95d0a447e9fc4e1f63d25cd88bca9e1abe.
Break master, not tested, blocks other pending merges.
|
|
[IMP] mail: improve email templates and simplify DOM
|
|
Below takes only one 'l', not two. Fix typo in
* tooltip of create button;
* mail demo data;
* comment in stock
This commit is related to task/bug ID 1870964 and closes PR #26099.
|
|
|
|
When someone assigns an activity to another user it is a good idea to
notify this user a new activity has been assigned to him. This is done
using the message_notify method that sends a notification either in the
Inbox either by email depending on the user preferences.
This commits is linked to task ID 1854820. Closes PR #25265.
|
|
As those are technical views used as data when sending some notifications
they should not be in the templates.
|
|
|
|
font size
Purpose is to avoid having '/' in record name. This is generally considered
as being an URL and leads to a specific display in most email readers. In
this commit we therefore remove '/' by '-'.
A use case is the name of payment receipts.
Font sizes in light notification template are also standardized to 13 and
11 px to better match the chatter layout. Emails are still bioutifoul.
This commit is linked to task ID 1843376 (and 1868112) and to PR #25349
(and #25889).
|
|
This commit introduces a new notification template. Its target is to be used
when sending payment-based templates like 'Send by email' for sale orders,
invoices or purchase orders.
Purpose is to separate the template content (payment information) from the
payment button (Pay and sign online) when sending those documents by
email. Composer and chatter should not hold the button. It should be added
only in notifications emails.
Technical solution is to have a somewhat-generic template available in mail
to be used in some specific actions. Another solution is to hide the
button but it breaks if people edit or remove the hidden content when
editing the mail in the composer without knowing it. As the button is
mandatory in those actions we choose to have it added by the notification
email.
Future commits will gradually use this template in some addons.
This commit is linked to task ID 1860049 and PR #25824.
|
|
----------------------
Summary
----------------------
The purpose of this commit is to improve the JS code of the `mail` module.
It applies the new coding guidelines and makes some changes on the design
of some modules, such as the old ChatManager module.
Here is a short summary of the changes that have been made:
1. New coding guidelines
- snake_case to camelCase
- prefix private attributes and methods with '_'
- jsdoc on most methods
- one class per module
2. Rename/Merge some classes
- 'chat manager' becomes 'mail manager' (internal) and 'mail service' (external)
- 'chat window manager' is now included in mail manager
- 'thread' widget now named 'thread widget'
3. New model abstraction for mail objects:
- modules 'mail.model.*'
- modeling:
0..1 0..1 * *
ThreadWindow <------> Thread <-------> Message
/ \
/ \
Thread With Cache Document Thread
/ | \
/ | \
Mailbox Channel Support Channel
|
|
DM
- Thread: the superclass of threads.
- ThreadWindow: the window component of a thread.
- Message: mail objects representing messages.
- Thread With Cache: threads that can be used with search view (Discuss app compatible).
- Document Thread: represents the thread part of a chatter.
- Mailbox: represents what was previously called 'static' channel, e.g. 'Inbox'.
- Channel: mail objects representing channels, including livechat.
- DM: special kind of Channel for 1:1 communication in the backend.
- Support Channel: special channel for im_support module.
This new modeling approach let us easily add features on all threads, such as the
possibility to put any thread in a small window.
----------------------
Known issues
----------------------
[Already Present in Master]
1. When the Discuss app is in the background with 'Inbox' as the selected
Thread, when clicking on a document thread preview in the messaging menu
of the systray, the rainbow man appears.
2. When a document with the chatter is in the background, when receiving an
inbox notification from this document thread, the document thread is
automatically marked as read, which removes the notification right away.
3. Sometimes, opening a DM window from the "blank" thread window does not work.
4. Reply-to feature on Inbox is not working: no message is sent in the document
thread.
5. On the first login of admin user with demo data, the inbox counter is wrong
(it displays 6, instead of 3).
Explanation after investigation:
> On page load, it fetches the correct number of Inbox messages (3),
but the server notifies of 3 needaction messages right away,
so it wrongly assumes these are new needaction messages.
> Not possible for web client to detect that these messages should not
increment the Inbox counter while keeping same API.
6. Notifications for new document thread messages only work when the user sets
'handle with Odoo' for the Notification Management in the preferences.
> due to notifications on the longpoll bus for document thread
messages that come from needaction notifications.
> requires server-side changes to send notification on the longpoll
bus to mentionned user.
[New]
7. When receiving a message on a unjoined channel, thread window flickers
('open' > 'close' > 'open')
Explanation after investigation:
> JS logic:
a) On auto-join, ask server to join the channel and get channel infos.
b) The info tells the channel is not detached, but JS code makes decision
to detach it, and tells server the channel is now detached.
c) From (a), server notifies on longpoll bus the state of channel, which is
not detached. The web client thinks that the window state of the channel
has been changed somewhere else, and the channel is now closed.
d) From (b), server notifies on longpoll bus the state of channel, which is
detached. The web client opens the thread window of this channel.
> The flicker didn't occur before refactoring because the web client was only
updating the model of channel when it receives the longpoll notification.
> Server behaviour on 1st longpoll notification is necessary for cross-tab
synchronization for channel window state.
> New design implies that model and view should be synchronized, hence the
issue now.
> Solution: remove server-side thread window synchronization and replace with
client-side synchronization.
----------------------
Hacks
----------------------
The module `im_livechat` now uses mail objects that are compatible with Message
and Window objects:
Modeling for messages:
AbstractMessage
/ \
/ \
LivechatMessage Message
- AbstractMessage: message compatible with the thread widget.
- LivechatMessage: message used by im_livechat.
- Message: message used with the mail manager.
Modeling for thread windows:
AbstractThreadWindow
/ \
/ \
LivechatWindow ThreadWindow
- AbstractThreadWindow: behaviour share between all types of thread windows.
- LivechatWindow: window used by im_livechat.
- ThreadWindow: window used with mail_manager.
The reason for these hacks are twofold:
1. Use the thread widget in the frontend and livechat external lib bundles.
2. Do not have a dependency with the mail manager in the frontend and external
lib bundles.
|
|
* increase logo size, because big logos are necessary;
* correctly set cellpadding / spacing to 0 to avoid loosing some pixels
when having several embedded tables;
* remove summary mail_notification as it should be used only to some
customer-specific part of emails;
This commit is related to task 51122 (and PR #24052).
|
|
Purpose of this commit is to allow moderation on incoming messages in
discussion channels. On some channels on which moderation is required
messages should be in a pending moderation stage. Moderators can accept
or refuse messages as well as always allow or ban messages coming from
a given set of emails.
Channels now have an option to be moderated. Moderators can be added on
channels. They have access to a specific UI in Discuss to see and take
action on messages waiting for moderation.
Concerning mail.thread message that are pending moderation are not notified.
It means nobody receives a notification about them. Moderation process calls
the notification once the message is validated.
Various features included in this commit :
* a model is added to store the decision about emails, allow or ban;
* access rights are updated so that only moderators can modify moderation
fields on message;
* specific bus notifications are send to moderated people as well as to
moderators on incoming emails as well as when a decision is taken;
* options are added on channels to send explanations to moderated emails;
* options are added on channels to write and send guidelines explaining
why and how moderation is performed;
* a reminder is send daily to moderators with remaining messages to moderate;
* discuss UI is adapted and a new channel is added below Inbox and Starred
giving access to moderation tools;
* chanenl UI is adapted allowing to moderate directly inside channels;
This commit is linked to task ID 29521. Closes #21921.
|
|
Purpose is to avoid mixing various data types in the same generic mail_data
file. We already have 2 crons and the upcoming moderation feature will add
some more. Let us put them in their file to ease the finding.
This commit is linked to task ID 29521.
|
|
It seems better for people. . Related to task #1825295.
|
|
Activities are quite personal and linked to daily jobs of people using it.
Being notified of all activities is therefore not considered as default
behavior and should be a choice done by users. Subtype linked to logged
activities is now not followed by default anymore. It is still configurable
through subscription widget or parent subscription (project/task for example).
This commit is linked to task ID 1824141.
|
|
Remove the support to replace emojis by images. Most browser
now support colored emoji or at least black and white emojis.
The emojis list have been updated to ensure a correct support
for most os/browser.
Users have the possibility to install fonts localy if their os does not
have one of the default emoji font installed.
After default os emoji font, one of twemoji, emojione or noto color
will be selected.
The emoji list is now hardcoded in js in order to reduce the number of
records in shortcodes.
Also include a small fix for livechat to display message field when rating
is bad.
Task #36898
PR #23689
|
|
This commit refactors f488dc58c37fdc7fd49df759165de641e213444b that added reminder feature in activities.
After merging it was suggested specifications were not correct and it has
been decided to move the whole reminder feature in note.
Reminders are now notes instead of activities. Now when having note appµ
systray proposes to create a note / reminder. A note.note record is created
with info given by the user. If a date is given in the systray quick create
then an activity is scheduled on this note.
This means user can create records in activity systray that are not
activities but notes used as reminders. Those will use the first availableµ
note column for the user.
As reminders are now notes the support of activities not linked to any
document is removed, as well as archiving activities and tests linked to
that behavior.
This commit has been not carefully tested nor in-depth reviewied. It is
considered as too important for the upcoming freeze. This closes task ID
1833628. Closes #24129 . Many thanks to @dpr-odoo for its quick development
and good work on this task.
|
