Development

This is about opentimesheet development. Contains technical and conceptual discussions and solutions. Primary audience is developers.

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

Permissioning - users and roles

This is about what permission we want to implement in opentimesheet.
My first proposal:

  • Group controllers can run all reports for projects in that group
  • Group managers can create, approve and close projects in that group
  • Group admins can add users to groups
  • Group workers are not existent

A role in a supergroup inherits to all groups within this supergroup.

Database structure - groups, users and roles

My first proposal for the groups, users and roles is as following:

  • There are groups and supergroups
  • A group is in one supergroup
  • There are users and roles
  • A user is member of 1..n groups in 1..n roles
  • A user is member of 1..n supergroups in 1..n roles

Roles are initially "Admin", "Manager", "Worker" and "Controller".
The entities group, supergroup, user, role have each two foreign key fields for mapping to legacy systems. The count "two" is a trade-of between 1 and many. Two should be enough to integrate to most systems.

Syndicate content (C01 _th3me_)