Groups improvements

Registered by YannickB (YOLO consulting)

Dear community,

Here is the blueprint of what we would like to do in order to improve the groups management in Odoo.

Blueprint information

Not started
YannickB (YOLO consulting)
Needs approval
Series goal:
Milestone target:

Related branches



First we want to add some features to the object :
-Recursivity, with for example "parent_id" field. Each members which belong to a child group also belong to the parent group, and so receive the communication of the parent group. Still not sure about the best way to implement it, maybe we should use the many2many group_ids native in Odoo.
-Administrators fields, a many2many field to res.users. It contains the users which can make important tasks for the group, like launch invitation for example.
-Improve Authorize group group_public_id field, which determine which users can see the group. Currently, we can only select a access right group res.groups, we shall have another field which have the same purpose but with another EDIT : After second though, this behavior is native with the "Selected group only" in public field.
-For private groups ("public" field), invitations shall be improved. Invitation shall be launched, and should be accepted by the user before entering in the group. Also, a user shall be able to candidate to a private group, and then be accepted or rejected. All theses actions must be done only by the administrators of the group.
-Link each to a res.partner, to ease some developments since partner is a central concept in Odoo. For example this is important for the marketplace module because the wallet (balance of all currencies) is located in res.partner, since partner has itself important links with the accounting module.

We plan to add a "type" field in the objet, so we can have several types of groups :
-"Free" or "Group of interest" will be the current native group. No particularity, just peoples who wants to regroup and speak together.
-"Circle" will represent a community who have to take decisions together. It have one many2many with teams and a one2many with the roles of the circle.
-"Team" represent a group of people which works together. It have one many2many with circles and a one2many with the roles of the teams.
-"Role" represent the peoples responsibles for certain tasks in teams or circles. No recursivity for this type of group, must be assigned to a circle or a team.
-"Assembly" represent the rank of the user in the community, and one user can only belong to one assembly. For example if we take the example of the OCA, one user can only be a member, a delegate or a board. Members, delegate or board are Assemblies.

Now lets see which are the relations with others modules :

Project module :
The main purpose of Team and Role type is the link they'll have with the project management. Essentially, a project should be assigned to a team and a task should be assigned to a role.
This way if a user join a team, he instantly have access to all the projects of the team. Same for the role, if the user responsible for certain tasks in a circle or a team change, the new user instantly have all the tasks of the old user. Such efficiency in task assignment is critical for communities were turnover can be really important.

Governance module :
In the future governance module, we need people which have decisions to make to regroup. This is the main purpose of the circle type and the governance module will be strongly tied to it.

Marketplace module :
We want circle and team to have a wallet in the marketplace, so the administrators can receive and spend currencies at the name of the circle/team. Also, each announcement can be made in the context of groups, so users can easily see which announcements was made in the groups they belong.

Let's take and example, we have a Circle USoftware of 50 people united by the fact they want to create an open-source software. In this circle, Mr X has the responsibility to coordinate the discussions of the circle, and so has the corresponding Role in the Circle. The Circle is a public group, so no need for invitation, and Mr X is one of the administrators of the Circle.

Some teams exists and are linked to this Circle, for example we have the team Design and the team Programming, both linked to the Circle. The administrators of the Design team created a project "Refactoring of the home page project". The Design team has Ms Z with the ergonomic role and Mr T with the integrator role.
The Design team plan to change the logo, and so create the task "Change logo" but unfortunately neither Ms Z nor Mr T has the necessary skills. So they click on a button in the task which will automatically create an announcement corresponding to the task in the marketplace, announcement at the name of the Design team but also in the context of the Circle USoftware. Wished price is 250€.

Everybody who has access to the marketplace can answer, but people member of the Circle can see it more easily. Ms J make a proposal of 500€ to the announcement, the Design Team would like to accept but they do not have enough money, so they speak about it to Mr X the coordinator of the Circle USoftware.
Mr X can't decide by himself to spend the 250€ from the Circle USoftware because it's against the statutes of the Circle. So he propose through the governance module that the Circle USoftware pay the missing 250€ with the wallet of the Circle. Each members has the opportunity to give his position through the governance module, and the proposition is accepted. Then Mr X go in the announcement to add the 250€ at the name of the Circle USoftware, and the proposal of Ms J is accepted.

The job is done, Ms J paid by the Design Team and the Circle USoftware and everybody is happy, the project is going forward :-)


Work Items

This blueprint contains Public information 
Everyone can see this information.