Add a link in the general settings to access easily the default_user form view in order to modify the default access rights
The default_user manager rights declarations in all the applications have been move in a noupdate="1" definition to avoid the manual configuration overwrittings
Coming from a bug in web_settings_dashboard. Invited user didn't have any rights
when created from the dashboard, which was leading to an error.
This bug leaded to a new discussion. Better to have basic employee having user
rights for all main applications. For bigger entreprises there is an admin that
will carefully remove extra rights, if necessary. The target is small businesses,
it makes sense that every way to create a user gives the same result.
In conclusion, each new user has a full access to the applications by default
How is it implemented ?
We added an inactive default user which original access right to the groups
'base.group_user' and 'base.group_partner_manager' in base. Each
application will extend the default user's access right by adding the maximal
access right for this application.
On user creation, we will use by default the 'group_id' field from the default
user. We will in the same time remove the ugly 'default_groups_ref' key which
was passed sometimes in the context for some fields in some views, and sometimes
nothing.
So, the user can modify the access rights for the default user, but he should be
aware that removing project user access rights for a default user will prevent
a *created on the fly in a task* user will not be able to access the task.
These two rules were used to restrict livechat users
to the read access to their own messages,
and allow livechat managers to see all messages.
Since 9.0, livechat messages are no longer
`im.chat.message` records (8.0),
they are now `mail.message` records, and this model
already implements its own security rules.
See `check_access_rule` of `mail.message` to know
more about the access rules of this model.
Therefore, these security rules are no longer necessary in 9.0.
Besides, it had as side-effect to restrict the access of
livechat managers for `mail.message` records.
For instance,
livechat users were no longer able to create customers.
opw-651958
There is no `to_id` field on the model `im_chat.session`,
but there is a `channel_id` field.
This is probably a copy/paste mistake, as the rule
just above had the same exact domain.
opw-646243
Migrate the models and controller to new API. Renaming xml id according to convention, renaming openerp tag into odoo tag. Add comment strings and documentations.
Add a generic bus for instant communication based on postgres LISTEN/NOTIFY and HTTP comet.
Both threaded and gevent greenlet mode are supported. Chat should now work on every platform.
im_chat improvements
- proper support for multiple windows
- present, away and offline status
- improved data model for multi user chat session
im_livechat improvements
- standard css js assets are now used
- qweb templates are now used instead of jinnja
Yannick Tivisse