Instead of looking for the "denied" permission, rather look for the "granted"
since there are three permissions: "default", "denied", "granted" - only
"granted" counts toward permission actually being granted
Closes#22633
Before this rev., terms in the activity systray dropdown weren't
translated because the user_context (containing the user language)
wasn't passed.
Complete c591e4e6
opw-805431
This test couldn't be executed within the classic JS web suite,
because it relies on mobile specific files that are rejected in
desktop. Now that a second web suite (for mobile) has been
introduced (see 9bc500948), we can activate this test.
An activity is always created with sudo, so it's useless to set the
image and the name of the "Administrator" all the time.
Now the image and the title of the assigned person is displayed.
opw:802759
When adding more than one recipients on mails a traceback appears.
This was caused because instead of doing a name_get by providing the partners ids as a list, we send them as arguments.
Which wasn't valid because name_get except a single argument.
opw #804691
In march 2017 saas-15 on activity message, the create_uid was displayed
with 26940f8d.
In november 2017 saas-14 an activity was always created sudo() with the
change 53ad585bf.
Thus in saas-15 we always have "planned by Administrator for {user}"
not making sense.
opw-804409
closes#22113
Before this commit, the user had the ability to scroll horizontally
on some form views containing chatter.
This horizontal scroll only appeared in mobile (Android and iOS) but
it wasn't useful.
Before this rev., the default filters were ignored in Discuss. The
SearchView was instantiated and correctly retrieved the default
filters. However, a first manual 'do_search' needs to be done by
the client action for the search view to provide the domain, and
for Discuss to correctly filter the messages.
Steps to reproduce the issue:
- In Discuss (e.g. in Inbox), add to Favorites a given search,
and tick 'Use by default'
- Leave Discuss, and then go back: the default filter correctly
appears in the search view, but the messages aren't filtered.
Adapt commit b92aaf1 for framework changes in saas-16.
That commit made Many2ManyTagsEmail widget display name_get gotten
dynamically. This allow to have 'show_email' context key working and
having the email displayed.
This commit use the new views (as of saas-16) to do the same change.
opw-801558
fixes#21812fixes#21523closes#21969
Before this fix, the chatter always showed dates of messages in military time format.
This was not the expected behavior, as the user could have had customize
the date and time format in the settings of the current language.
Steps to reproduce the issue:
1. Set Odoo in English
2. Settings > Translations > Languages > English
2.1. Set Date Format to %m/%d/%Y
2.2. Set Time Format to %I:%M:%S %p
3. CRM > (Select any opportunity with at least one message) > Mouse hover on elapsed time (e.g. "an hour ago")
Expected:
- It shows the customized time format (e.g. 11/07/2017 5:33:36 PM)
Results:
- It shows the military time format (e.g. Tue Nov 07 2017 17:33:36 GMT+0100)
opw-781647
Before this revision, it was not possible to display a chatter inside a <sheet>.
As the chatter is reused (when switching in edit, records, etc.), it is detached
(to keep its handlers) before updating the form $el.
The problem here is that the chatter was detached in `_updateView` from
`$form.contents()` where the chatter is a root element ; when setting the form
view html, the chatter was thus still present. This was thus only working
correctly if the chatter was a direct child of <form>.
To keep it displayed in all cases, we now detach it at the chatter node
rendering.
Closes#20032
Before this commit, it was not possible to choose the user you want to
chat with in a chat window anymore. This was because the dropdown that
suggest the users appeared under the chat windows since commit
https://github.com/odoo/odoo/commit/7b965a9673a9124e6e045b8a290a156eed402ad5
Indeed, the mentioned commit changed the z-indexes so that chat windows
are still usable when a modal is opened. This was done by making the
chat windows always have the greatest z-index... forgetting this would
make them appear on top of their own autocomplete dropdowns.
This commit restores the feature while keeping the ability to talk while
a modal is opened. See code comments for details.
opw-785162
Steps to reproduce the bug:
- Login as demo user on runbot 11.0e
- Open a contact
- schedule an activity, "todo" , assigned to Administrator
- Clicking on the "i" icon next to the planned activity,
you see that the "Created by" is "Administrator" , which is incorrect
Since this commit: 53ad585bfc, the field
create_uid is always 1.
opw:783650
Do not forward-port this after 11.0
After sending a message, if one switched in edit mode in the form view, the
created message disappeared.
This is because the model is not aware of messages (they are created through
their own routes, message are not handled as other one2many fields with commands)
and the widget was reset with a new datapoint instance when switching in edit mode.
In this rev. we keep the model informed of the new messages by directly writing
the message ids in the datapoint.
Note that the includes on FormController and BasicModel are one in the
form_renderer.js file to fix this issue in existing database without adding
files. Another revision will be done in master to add the correct files.
opw-781353
Here is what could (sometimes) happen in community:
- the point of sale tour is started by the runbot
- it loads the '/web' url
- this instantiate the mail client action (init)
- the tour sees that the POS link is in the dom and clicks on it
- the action manager destroys the discuss client action (before its
start method is called)
- the destroy method from the client action is called, this.$buttons
is not set, the destroy method causes a traceback
Here is what could (sometimes) happen in community:
- the point of sale tour is started by the runbot
- it loads the '/web' url
- this instantiate the mail client action (init)
- the tour sees that the POS link is in the dom and clicks on it
- the action manager destroys the discuss client action (before its
start method is called)
- the destroy method from the client action is called, this.$buttons
is not set, the destroy method causes a traceback
In the iOS app, the content immediately ceases to
scroll when you remove your finger from the touchscreen.
Now, he content continues to scroll for a while after
finishing the scroll gesture and removing your finger
from the touchscreen.
The speed and duration of the continued scrolling is
proportional to how vigorous the scroll gesture was.
This Css property is the only way we find to have
the same behavior in the android app and in the iOS app.
This commit fix 596e88f , using a better bg-color in order to improve
text readability. It apply also apply a minor padding-left to avoid
having text attached to the coloured div border.
Moreover, the bg-colour can not be applied to activities thread.
The little history behind: remove the bg-color was decided by fp and
the UX dep. I’m not aware if 596e88f is approved or not, but the final
result was not acceptable.
This commit will restore the chatter entries UX defined for v11
and accidentally removed on 7a91d87.
In v11 unread systray chat entries have white bg and bold text. Entries
that have been read, instead, should be less emphasised with
light grey bg and normal font weight
This commit will restore the chatter App icon design defined for v11
and accidentally removed on 7a91d87.
Apps icons should NOT have a circular shape in order to keep branding
consistency.
Nicolas Martinelli