dimagi/core-hq — pull request #937 by mwhite (2013-04-25 00:42:02+00:00)
Title: add hierarchical reporting groups using existing group metadata

HSPH has a few user group hierarchies where they want linked user
selectors on reports that show children dependent on what parent you've
selected.

There doesn't seem to be an obvious way to do this. There had been
group names hardcoded in containing the parents and then I hardcoded a
particular relationship between the parent username and the name of the
group that would contain all their children, but this breaks when groups
get renamed.

There was the possibility to handle this by creating a new fixture data
type for each type of user relationship and then adding fixture items
containing one user and one group each.

However, I thought I'd just implement it with groups using the existing
metadata interface. I did this by adding semantics to these group
metadata properties:

```
user_type: indicates that all of the users in this group are of a
certain type. This is used to identify the root users for a given
hierarchy but can also be used to validate the types of descendant
users in the hierarchy if there are groups for their types too.

This is simply any string.

owner_name: for a one-to-many relationship group, the raw_username of
the owner
owner_type: the user type of the owning user.
child_type: the user type of the child users.
```

I've tested this with up to a 3-level tree. It also isn't integrated
anywhere yet (I added one to HSPH but waiting on setting up groups on
prod to integrate it with the reports).

I don't see any reason this model wouldn't work permanently for
hierarchical reporting groups. It doesn't constrain the types of
hierarchies that can be configured (for example, it allows overlapping
hierarchies), and I don't think there's going to be a much more
efficient way to query things without introducing a huge amount of
denormalization and complexity. And it shouldn't be hard to adapt if we
want to make these metadata properties first-class citizens of the group
model.

Haven't really thought about the implications for hierarchical case
sharing, though.

If we don't want this then I can easily swap out fixtures for groups in
the algorithm to meet the immediate needs for HSPH.