odoo-communitytools-team team mailing list archive
-
odoo-communitytools-team team
-
Mailing list archive
-
Message #00002
Specifications for groups improvement in CommunityTools
Dear community,
Here is the specification of what we would like to do in order to
improve the groups management in Odoo. A blueprint is available here :
https://blueprints.launchpad.net/openerp-communitytools/+spec/group-improvement.
First we want to add some features to the mail.group 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 mail.group. EDIT : After second though, this
behavior is probably 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 mail.group 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 mail.group, 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.
Example
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 :-)
We hope to start the development this week, if you have any feedback
feel free to answer this mail.