To be displayed correctly on odoo app (In a given category and not only in all or hidden)
the module category in the __openerp__.py file should be one of these:
"Accounting",
"Discuss",
"Document Management",
"eCommerce",
"Human Resources",
"Industries",
"Localization",
"Manufacturing",
"Marketing",
"Point of Sale",
"Productivity",
"Project",
"Purchases",
"Sales",
"Warehouse",
"Website",
"Extra Tools",
'Accounting & Finance' will not work, as 'Project Management', ...
Basicaly, do this RPC once, at webclient startup, to get the next notification.
Do the RPC again when the notification is displayed to get the next one.
When an event with alarm is created, edited or removed, trigger an event on the
bus for all involved users (the attendees) with an update of their next
calendar notification.
Since the new QWeb engine, `groups` directives on template
rendered in a route with auth=none is simply ignored, since
all is done as SUPERUSER_ID, it was impossible to instanciate
the webclient to check if the session is valid and to display
meeting info or redirect to event form view.
It seems that we don't want to fix this because routes auth=none
are rare, and special. So it is not considered as a bug.
The fix for calendar is, however, to do redirection or template
rendering server side.
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
[FIX] account: move some ir.model.access to sale module
[FIX] payment: Move some ir.rule to website_sale
[FIX] stock: move some ir.model.access rule to sale_stock
[FIX] project: Move some ir.model.access rules to crm_project_issue
[FIX] mrp: Move some ir.model.access rules to sale_mrp
[FIX] calendar: move some ir.model.access rules to crm
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
[ADD] sales_team: See own documents => See only his sales team
Moved the "User: Own Leads Only", "User: All Leads" and "Manager" groups from sale and crm
into sales_team module. Add the record rules so that user can see only his Own Sales Team
if "See Own Leads" is sales right and can see all sales teams if he is having sales rights
of "See All Leads" or manager.
In odoo at many places the filter items are having repeated strings eventhough the
fiter works differently , so find all the places where this happens and give
proper string to each filter..
This branch need more testing instead of doing 10 fixes. A lot of issues are occuring
when installing modules in different orders.
This reverts commit fa6e415cdb.
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
Also:
- keeps unticked filters unticked when deleting a filter or adding a new one
- correctly tick filters when clicking on the partner's name (that code was
broken)
- remove reference to instance.web introduced by a forwardport
- wrong use of self in CalendarView's init()
When loading a calendar view with a partner_id in the context, the sidebar's
filters should be disabled by default to only display events related to that
partner.
Before this rev., the events were loaded twice:
- once with the date range as domain (and optionally the content of the search
view),
- once with the date range and the partner_ids of the sidebar's filters (and
content of search view).
The first loading was therefore useless, and might also be very costly.
Christophe Simonis