Currently, when clicking on the systray activity action icon and click on any
record from the activity, kanban or list view, not redirecting to its form view.
This commit adds the form view for that action and now click on record will
redirect to its form view.
task-2198480
Closes https://github.com/odoo/odoo/pull/46877closesodoo/odoo#47208
X-original-commit: 3fd30316c0af9a6ca2ea4962f2e2f832e68dee54
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The chatter's attachment box has an horizontal overflow when adding at
least 1 attachment.
This is due to a negative margin applied on the attachment list/previews
not matching its container's padding (3px vs 5px).
This commit reuses the SCSS variable dedicated to this margin around the
attachment list/previews and apply it correctly to the chatter's
attachment box.
Task ID: 2194025
X-original-commit: 3a7eb3fe97541855ae893514f8b98cbfe6c1a7e4
A horizontal scroll appears on medium to large screen sizes in the
form's chatter sidebar (e.g. between 1534px and 1619px, when all modules
are installed).
This commit restores the padding set by Bootstrap for `.nav-link`
elements instead of a fraction of the grid gutter's (?) width then
applying slightly smaller padding.
Task ID: 2193950
X-original-commit: 7bc8b577d822b057d1bccf881b9c4b1ee127a728
Issue
- Install CRM, Discuss
- Have 2 languages (e.g. french english)
- User 1 > French
- User 2 > English
- Create an activity as user 1 for user 2
- As user 2, check discuss > history
Notification received in french
Cause
mail_activity action_notify method uses
the context language which is the active
user language.
Solution
If user 2 has a language set, use this
language for translating body template (self)
and activity type (activity)
OPW-2205409
closesodoo/odoo#46800
X-original-commit: ccfe573b4eee82de92d130addb745f68b3fd3bd9
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
When mailgateway receives an incoming email being a reply to a thread but
containing a recipient being an alias linked to another model, it is
considered as a forward to that new alias. It therefore skips the reply
step in routing and applies rules related to new thread, aka checking
all recipients.
Consider this use case: receives a email on a task from "project@domain"
project being the alias of the project which creates new tasks when not
routing replies. Reply / forward it to "project@domain, sales@domain" in
order to transfer it to the sales team (sales alias creates new leads).
As this is a forward, both aliases are evaluated, leading to a new task and a
lead which is not what we expect.
We solve this issue by removing alias linked to the ignored reply model
when considering recipients.
PR #46764
Task ID 2121551
closesodoo/odoo#46784
X-original-commit: 7cff7787cb42cc9d3d0cb4c5af41a9f09d59d1ff
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
/!\ This commit is a manual forward-port of two PR targetting originally
11.0: #40442 and its fix / partial revert #41042. /!\
Purpose of this commit is to check all recipients of incoming emails when
trying to determine the route to apply. Notably
* an incoming email should be considered as a write to catchall only if all
recipients are catchall. Catchall + a valid alias should take the alias
into account;
* an incoming email sent to the bounce alias should be considered as a bounce
even if another valid alias is in recipients and whatever the order. Indeed
it indicates an issue and bounce is considered as more important;
* forward to an alias linked to another model should check all recipients
and not only the first one. Otherwise reply_alias, forward_alias is
considered as a reply whereas it should be considered as a forward when
considering all recipients;
Tests are added according to those specifications.
Please see original PRs for more details about the content, the comments
done on it and the various discussions.
PR #46764
Task ID 2121551
X-original-commit: df00bd2d3bddf9a2b56e8554380669025e146d21
Currently, to activate/deactivate records with the 'active' checkbox
user has to switch to edit mode of the form.
So the purpose of the task is to allow the user to activate/deactivate
records from the readonly mode of the form view.
In this commit, we set widget='boolean_toggle' on the 'active' field in form
view.
closesodoo/odoo#46567
Taskid: 2206794
Related: https://github.com/odoo/enterprise/pull/8918
Related: odoo/enterprise#8918
Closes: #46567
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When there is no intersection between the allowed companies of the current user
and the target user, the `with_user` would lead to the company check always
failing.
opw-2197955
closesodoo/odoo#46606
X-original-commit: ceee2c05f8a4fc69b8ae34469ac56a055ba7b7cf
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
When a user is created, its partner_id shall not have any company_id.
A test has been added to check that in 'base/test'.
Update test_mail tests by setting a company to partner_id linked to users
as now, by default the partner linked to a new user has no company_id.
closes odoo/odoo#46515
Task: 2198688
Forward-port-of: #45900
X-original-commit: 187b12fc5715721efdd9af283e086dfc3f856fc2
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit fix the o_mail_preview_image css by applying the same
rules as desktop.
Task ID: 2200099
closesodoo/odoo#46328
X-original-commit: f4a106c7fa5ba21bba2811d5c51cbf5bf57f4dc9
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Revision on https://github.com/odoo/odoo/commit/8e5b6ab02aa95c204ea7bd241e6b8944d5972d43
Intent of commit above was to remove server-side synchronization of
chat windows in mobile. To do so, it prevented sending RPCs for chat
window state in mobile, in addition to not automatically adapt state
of chat windows in mobile from longpolling notification.
This implementation, while functionally working as intended, had
disturbing intermediate logic that could potentially lead to bugs
in the future. Specifically, on mobile, new channel did not directly
trigger a re-render of discuss widgets. However, and thankfully, the
related new message was triggering the rendering, so that UI
correctly has channel and its notification.
This commit simply improves code so that new channel always triggers
a rendering, even in mobile, like before the commit above. Of course,
to preserve the intent of not synchronizing chat windows in mobile,
new detached channels must still not auto-open a chat window, and
this commit clarifies this intended behaviour in the code.
X-original-commit: 1046d063ca46aacb1e186599b5d4a02ef9c8e18d
Follow up of be06eb47bdf8b5f2cc281e3986818faf59e3a616 . Even if postgresql < 10.0 is not officially
supported this fix allows to keep compatibility with older postgresql.
closesodoo/odoo#46243
X-original-commit: 7e218be37cf0bc2c2c4fd4284b93ba99de679692
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently the message for help tooltip of auto_delete field is not sufficiently
clear for user to understand.
In this commit, improving message for help tooltip by adding some extra details
in it so user can easily understand about it for models mail.mail, mail.template
and wizard mail_compose_message.
Task-2055702
Closes https://github.com/odoo/odoo/pull/45063closesodoo/odoo#45063
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When using the Discuss app (not the systray's thread window) on a small
device, it is not possible to scroll through the discussion (cf. tab
"Chat" or "Channels").
Steps to reproduce:
* Go in discuss (in mobile)
* Go to tab chat or channel => BUG
NB: you must have enough element to test the scroll
This bug is due to the commit odoo/odoo@3ad7706560.
Before it, the styles as interpreted by the browser looked like this:
.o_mail_discuss_tab_pane {
overflow-x:scroll; // explicitly set in discuss.scss
overflow-y:auto; // implicit ; due to the overflow-x rule
}
But by removing the overflow-x rule, the styles ware interpreted as:
.o_mail_discuss_tab_pane {
overflow-x:visible; // implicit ; due to the absence of overflow-* rule
overflow-y:visible; // implicit ; due to the absence of overflow-* rule
}
In addition, the parent element had an overflow: auto rule scoped only
for desktop-like screens.
This commit fixes this issue by unscoping the overflow: auto rule on the
parent, allowing to scroll the messages' list in both desktop-like and
mobile-like screens.
Reference:
https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-xclosesodoo/odoo#45964
X-original-commit: f4b22af7ed28d3515d77bfd76691aba1129581b1
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
- In some cases when trying to open a discuss conversation a
traceback can occur because of the usage of a local variable
before its assignation.
closesodoo/odoo#45867
X-original-commit: 47bec812a36c1e41bdb525439dfd18a208e1dd79
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
When more than one user are linked to the same res.partner and this user is assigned to a task or a sale.order
as many email notifications will be created as there are users linked to the same res.partner.
This won't send more than 1 email, but multiple mail.notification
records will be created.
This causes duplicate entries in the mail.notification table, and can
crash when an old unique constraint is still present in that table (from
earlier Odoo versions)
To prevent this, we deduplicate the notifications and order by notification
type to get 'email' first in case the user have different notification
type ('email', 'inbox').
How to reproduce:
- Create a first user test1
- Create a second user test2
- Merge the contact test1 and test2
- Create a customer customer
- Set the user test1 as salesman
- Create a new sale.order with customer as partner
Add a test to reproduce the pathological scenario
Solution
add distinct on partner.id and order by partner.id,
users.notification_type
closesodoo/odoo#45386
X-original-commit: 00f36c60e4790c8f5341cbc4f2c67e22e6d68f87
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Before this commit, the popup activity in kanban was rendered using
the position of the button. So the left popup was nearly in the center
of the screen but the width is too large to be contained on the screen.
After this commit, in mobile, the popup activity in kanban will be
placed on the left of the button to avoid to go outside of the viewport.
Steps to reproduce:
* Go to sale app (in mobile)
* Click on the activity button of a kanban card (clock icon) BUG
Task ID: 2198429
closesodoo/odoo#45860
X-original-commit: 392c8a57df798d92b8be73d743b690891cf2fda2
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
When a field is related, defining a selection or selection_add will
have no effect and the paramater is ignored.
Log a warning and fix all fields badly definied
Closesodoo/odoo#45716closesodoo/odoo#45832
Related: odoo/enterprise#8613
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce:
- install crm
- go to any lead and schedule an activity in the mail thread
- select "email" as activity type and type some text in the note field
- change the activity type to "call"
Previous behavior:
The text you had in the note field is erased even if there
is nothing set as a default message
Current behavior:
the note field gets erased only if there is a default message set
for the current activity type
opw-2195368
closesodoo/odoo#45603
X-original-commit: 1445b694e6111727d93d548f2830c53180fb9aa7
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, when receiving a needaction message while messaging
was not ready (i.e. `/mail/init_messaging` not resolved), the web client
crashed with the following error message:
```
TypeError: Cannot read property 'incrementMailboxCounter' of undefined
```
This happens due to reception of needaction message incrementing counter
of mailbox Inbox, but this mailbox is only added after messaging is ready.
This commit fixes the issue by directly adding inbox mailbox on starting
the mail service.
closesodoo/odoo#45442
X-original-commit: 741acb9f48f2d3542549791a8fd7d6fb318bc862
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When you read a record with the document viewer on the right side
that you don't have write access to this record
and the message_main_attachment_id was not yet set on the record
the document viewer try to set a value for message_main_attachment_id
that raise an access error
Set the value is not important but the popup
Access error can be really annoying
closesodoo/odoo#45378
X-original-commit: 74c36e6bc59af241ea162f042015f637880f1911
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
* modify client-side domain normalisation to error if the domain is
invalid (not enough terms / segments for the number of operators)
* add better error reporting to attrs / modifiers parsing
* add a few layered error augmentation to provide clearer context
e.g. "error: invalid domain <thing>" is helpful but "error while
parsing modifiers for field foo: modifier invisible: invalid domain
<thing>" is much more helpful
* rework _evalModifiers to deduplicate it in order to more easily
implement this contextual augmentation
* test that improper domains are properly found improper
* fix a bunch of incorrect attrs domains
* also removed an apparently undefined (& unused) "options" argument
to a _applyModifiers call
closesodoo/odoo#44642
Related: odoo/enterprise#8175
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
The customizable "out of office" text was removed from the editable views as
part of task-2053585, but some places in the code were still using it, even
though it was never set anymore.
This commit removes the obsolete code.
Part of task-2171864
closesodoo/odoo#44968
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, no recompulation were performed at the end of the
tracking procedure. This is because the main flush() occurred before
the tracking of values. The absence of flushing is problematic in the
case where the tracking is used to create/update records.
closesodoo/odoo#44851
X-original-commit: c60da49a1d81fa73b60135185d5b706eec771475
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
How to reproduce
================
Have a portal user commenting a task on the customer portal. He may experience
a crash if previous message / first message is not available, for example
if it is internal or not published.
This is due to reference computation used in outgoing emails as it is based
on parent messageID. Accessing it crashes although it should not as it is
used only for technical purpose.
Fix
===
In this comme we fix that issue by browsing the reference message as sudo
to access its messageID. A test is added to avoid regressions.
Task ID 2061760
PR #36845closesodoo/odoo#44765
X-original-commit: e94349ed65e05a40af6e690e366de81fc5aa6725
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jpr-odoo <jpr@openerp.com>
Follow up on 4f5334a081
Before this commit, thread was not re-rendered correctly in Discuss
App when user clicked on "Mark as Read" from Inbox and then changed
conversation in a narrow time frame.
This issue was discovered from a test that failed undeterministically
on rare occasions (once every hundreds of builds on Runbot):
```
QUnit test failed: "mail > Discuss > all messages in "Inbox" in "History" after marked all as read"
[message: "there should be 30 messages in History", actual: "0", expected: "30"]
```
This test crashed due to the rendering of Inbox after message fadeout
animation that overwrote the rendering of History. As a result,
thread widget indefinitely displays Inbox content, which is empty.
The HTML content of Discuss during the crash shows that breadcrumb
and discuss sidebar correctly have "History" as the active thread,
but thread widget still shows "Inbox" as content:
http://runbot.odoo.com/runbot/build/1092504
This commit fixes the issue by re-rendering of the thread with
message fadeout animation only if the active thread has not changed.
closesodoo/odoo#44585
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit prevents sending a notification within Odoo when a
message is posted from a mailing channel to a user whose notification
management preference is set to "Handle by Emails".
Task-ID 2033302
closesodoo/odoo#36000
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, models with the `_transient` flag were ignored in
ir.model.access verifications. Only an implicit ir.rule with the
domain (create_uid=user.id) was applied to avoid most side effects.
The problem is that, often, the security does not lie in side-effects
of abusing of somebody else's wizard record but in the fact that the
wizard methods blindly trust only the right users are creating these
records. Too often, too many sudo were used and creating wizard with
chosen values could lead to an abuse scenario.
Instead, explicitly require the developer to declare security rules
the same way as on any other model.
closesodoo/odoo#43306
Task-id: 1863044
Pad: https://pad.odoo.com/p/r.c1befa51103ed3b955a427971eb19719
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
Purpose
=======
Before this commit, the method _mail_find_partner_from_emails could
return a list mixing partner ids and partner recordset, that could
lead to issue when trying to read the different elements.
With this commit, we ensure that we return a list of records only.
closesodoo/odoo#44608
X-original-commit: 2fbbbd8609fd2e08545ddb1ab8e2d7d22ee4d292
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In 0.15 accessing werkzeug.urls functions directly through werkzeug
is deprecated, the shortcut will be removed in the eventual werkzeug
1.0.
Fix existing uses of these shortcuts. Also cleanup some imports when
they're not far from a werkzeug* import being altered.
Steps to reproduce:
- install sales
- create a new quotation
Previous behavior:
the avatar next to the author's name is empty in the mailthread
Current behavior:
avatar is displayed as expected
opw-2187231
closesodoo/odoo#44407
X-original-commit: 24ba9f9954a71eba46d44fe242cd2e6dba125da6
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
Follow up on 255f7219a9
The issue is still happening.
With the current commit, we will be able to know for sure if it happens because
we don't wait long enough, or because the messages are never appearing.
closesodoo/odoo#44471
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
`AccessError` requires the argument `msg`. Therefore, even if this error
is catched, we need to provide one, otherwise a `TypeError` is raised.
opw-2183184
closesodoo/odoo#44452
X-original-commit: cdefbf8d66e42d88d845dd621e0306cb55c5f79a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Currently, 'Exception' ativity type is visible in dropdown list of schedule
activity. It is used by the system to generate warning activities on records.
It is not meant to be used by the user when scheduling activities manually.
By, giving active=false on mail.mail_activity_data_warning, we can hide
'Exception' activity type in dropdown list for user but available for the
system to generate warning.
task-2168569
closesodoo/odoo#43549
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, when clicking on a channel mention from a chat
window, it crashed with the following error:
`TypeError: channel.detach is not a function`
This happens due to `MailService.joinChannel()` returning a promise
that is resolved with channel ID, instead of a channel object.
`channel.detach()` becomes `<Number>.detach()`, which is treated
like `undefined()`, hence crash.
closesodoo/odoo#44329
X-original-commit: 710fda06c3b30ff2267fcc1d123f15ce031b6f3a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, the CSS rule handling the "activity" of the modals
(their z-index compared to the one of their backdrop) was global and would
interfere with front-end or custom modals which do not use the static Dialog
methods giving them the "active" class.
Now, the rule has been inverted: the z-index of a modal is only changed when
it is given an "inactive" class, thus only impacting the modals instantiated
via Dialog or Owl Dialog classes.
closesodoo/odoo#44067
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When simply need to parse a domain, it is easier
Add .strip() on ir.ui.view as ast.literal_eval produces an syntax
error if the node starts with spaces (as done in the xpath of
hr_attendance.view_employee_form_inherit_hr_attendance)
closesodoo/odoo#43831
Related: odoo/enterprise#7894
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In order to prepare the future, we want to convert everything in Owl.
This commit converts the activity renderer.
closesodoo/odoo#42278
Task: 2149408
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Purpose
=======
Clean the context to get rid of residual default_* keys
that could cause issues afterward during the mail.message
generation. Example: 'default_parent_id' would refer to
the parent_id of the current record that was used during
its creation, but could refer to wrong parent message id,
leading to a traceback in case the related message_id
doesn't exist
closesodoo/odoo#43830
Taskid: 2176445
X-original-commit: 82d2d581a2590a9c782cbc71b5005a4198b70d77
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Hiral Bhavsar