Subgroups

Discussion forum about Anuko Time Tracker
Post Reply
Nik
Posts: 445
Joined: Wed May 26, 2010 5:55 pm

Subgroups

Post by Nik » Fri Nov 02, 2018 8:31 pm

I am starting to work on subgroup support in Time Tracker.

This thread is to discuss this feature and suggest ideas or raise concerns about it.

In a nutshell, I plan to consider an organization (identified by org_id field) consisting of a tree of groups of users (identified by group_id). Each group has a parent_id, which is null for top level groups.

To keep things simple, each subgroup is totally independent. Everything works like now. But users from a parent group having the manage_subgroups right can enter a subgroup and assume fuil control. I plan to accomplish this via an additional dropdown on top of some pages, which will allow for simple navigation between groups. Similarly to how we select an on-behalf user now.

Question arises about access checks and rights to a subgroup. Proposed approach is:

- Maintain parent user access rights and rank as is in its home group, how it works now.
- If user has manage_subgroups - allow navigation down the organizational tree (but not up) keeping access rights intact.
- If a parent user is in a subgroup - adjust its effective rank to maximum so that access to all users data in a subgroup becomes possible. This access is limited according to a set of rights the parent user has. For example, if the parent use can do something with regards to other users (such as track_time, then it applies to all users in all subgroups down. But if the parent user cannot do something in home group, they cannot do it anywhere.

This approach shall allow us to use the same set of functions in subgroups, without writing new code. Consider the following situation: user logins to Time Tracker, gets redirected to time.php, where we see a subgroup selector and a user selector. On initial entry the group list is a home group plus all immediate subgroups, and the user list is the list of users from the home group (adjusted for user rank accordingly). After navigating into subgroup, the group list changes to include parent group, current group, and all immediate children groups, while the user list now contains ALL users from the currently selected subgroup (as user rank is now set to max in context of a subgroup). To populate group list we will use getGroups function. For users: getUsers. The same functions are used for home group or subgroups. Adjusting effective rank accordingly in subgroups allows us to get a complete list of subgroup users (not filtered down according to original user rank).

This is a risky feature. Among other things, export-import needs a revamp to accommodate subgroups.

Nik
Posts: 445
Joined: Wed May 26, 2010 5:55 pm

Re: Subgroups

Post by Nik » Thu Nov 08, 2018 11:01 pm

With regard to export-import, as it is currently being re-written, both export and import will be re-designed, and the format of the XML will change for us to be able to incorporate subgroups nicely.

XML format will change to something properly nested like this example:

Code: Select all

<?xml version="1.0"?>
<org>
  <group name="Parent Group" ... >
    <roles>
      <role id="1" name="User" ... ></role>
      <role id="1" name="Supervisor" ... ></role>
    </roles>
    <users>
      <user id="1" name="parent" login="parent" ...</user>
      <user id="2" name="user_1_in_parent" login="user_1_in_parent" ...</user>
    </users>
    <group name="Child Group" currency="$" lang="en">
      <roles>
        <role id="1" name="User" ...></role>
      </roles>
      <users>
        <user id="1" name="child" login="child" ...</user>
      </users>
    </group>
  </group>
</org>
Notice how group elements are located inside one another with everything else inside group node.

I plan to use recursion to export groups one at a time to a file.

New import now has to do 2 passes through the file:

1) To determine if we have a login collision - need to parse all groups for that (in other words the entire file as groups are nested within one another).
2) Do import of data in the second pass.

To be able to do import in ONE second pass and easy, the order of entities in the XML must start with roles section and build upon it adding more entities as we go along and be able to insert data into the database as we parse each tag.

For example, as user has a role_id and an optional client_id, therefore we must have roles and clients in XML first (before users), and so on. I will add more details as things become more clear. For now, the order in each group:

Code: Select all

roles
tasks
projects
clients
users
other entities
nested groups in the end
Another thing is getting rid of CDATA sections in XML entirely. This will allow us to consolidate ALL processing at tag start - which should improve maintainability of the entire import code. The idea is to keep things simple: hop along the file processing start tags only, collect all attributes from within and do database inserts right there. New file format described above makes sure that we can prepare all required mappings for entities (between database and xml ids) right before we process each new tag. For example, we have roles and clients imported already before we start with users and other things.

Post Reply