Projects and tasks - structuring time capturing
When capturing a time record it must be assigned to at least a project. Additionally I would propose to introduce tasks - but make them optional because not everyone needs this granularity (input them as free-tagging vocabulary).
Also, there should be "superprojects" to have a two-level hierarchy. I am not a fan of multi-level hierarchies cause it's too much work with the SQL and it makes everything more complicated and slower than necessary.
- A project is in one superproject
- A project is in 1..n groups
- A task is in 1..n projects
- A users works in 0..n projects in 0..n roles (default is his role in the project's group)
- A time record is assigned to a user, a project and optionally a task
So, the group roles are kind of superroles for the project within this group...
Is that to complicated?
Subscribe comments
Comments
I think it is too complicated. As I wrote in my comment about the database structure, having supergroups is not necessary in my opinion. We should not define the hierarchy that is to be used. Imagine we implement superprojekt/group-project-task-role as hierarchy. People might need milestones. Should we add them above or below projects?
I'm not sure wether free hierarchy is that much more complicated.
daniel, opentimesheet is not about project management - it's about time registration!
If we're done with opentimesheet, we can create a next project "openprojectmanagement" :-) that is using opentimesheet for time capturing.
I think the restriction on core focus is vital for success.
We are not aiming to build a next Achievo.
OK, no milestones.
What I suggest is that we do not enforce a granuality. No Projects, No Tasks, No Milestones. Just units (what was called groups, could also be called project, task, or block) that consist of other units.
So no assumption about the hierarchy. There are units that might be part of other units. Whatever a "unit" is.
It is probably slightly more complicated to read the data recursively than from a given two level hierarchy. However, I think it is worth it: If there is the need for "supergroups", then there is probably also the need for "supersupergroups" and "sub{sub}groups".
Ok, so what foreign keys would be stored with a time entry?
The foreign keys are:
time_entry:
foreign key: group
group:
foreign key: parent_group
Cases where you have to search time entries for a group:
Cases 1 and 3 are simple.
Cases 2 and 4 are relatively simple to solve if we introduce a group_tree-table. Whenever we add a group (or assign it as subgroup) we update this table to contain all parental groups for the group:
group_tree:
foreign key: group
foreign key: parental group
Example:
We have the following groups:
1 Root (parent_group: NULL)
2 Home (parent_group: 1)
3 OTS (parent_group: 2)
4 Mac (parent_group: 2)
the group_tree contains:
2 1
3 2
3 1
4 2
4 1
Now we add a new group (5) "Frontend" that is a child of (3) "OTS": Starting with the new parent we climb up the parent groups, adding new entries to group_tree as we do so:
OTS (5 3) -> Home (5 2) -> Root (5 1) -> done
With this table, fetching all time entries for OTS is (case 2):
select *
from time_entries t, group_tree g
where t.group = 3
or (t.group = g.group and
g.parental_group = 3)
Case 4 (get all parent groups of a given group "3") is
select parental_group
from group_tree
where group = 3
union
select 3
Ok, that's a cool solution. We should keep the group_tree table up-to-date with triggers (possible in MySQL 5).
Now, what's a group like in it's business occurrence? Speaking in projects and tasks, is the "project" one group or is the "project|task" one group and the "project|task2" another group?
"Project" is a group, "Task" is a group (and a subgroup of "Project"), "Task2" also.
For opentimesheet everything is a group. It depends on the user to give her groups a meaning. Let's say she creates a group "OTS" which acts as project. Then she creates two subgroups to "OTS" named "Implementing bugs" and "Fixing bugs". These subgroups are seen (by her) as tasks. Perhaps she sets a flag on "OTS" to disallow time entries to the group/project but of course she does allow time entries on the tasks.
Since all reports should be capable of running including or excluding the subgroups, she could get reports for the project (report on OTS including subgroups) and for each of her tasks.
Finally she could add another group "OpenSource". She would change "OTS" to be a subgroup of this group. This does not change anything for "OTS" - it's still a project - but "OpenSource" could be seen as "superproject" or "business area".
Great and yes, that's all fine!
Let's do it this way.
Next discussion should be about users, roles and permissioning.