Here's one possibility that depends greatly on the behavior of the various
apps used to create the data that the secretary needs to edit. You could grant
the secretary "write" on the boss. If all the apps that the boss uses on the site
set the data's context ID to the boss himself, then that'll do the trick.
This would have the potentially adverse side effect of giving the secretary
write permissions on the boss's user profile, which might be a good thing in
your case.
Of course if the boss does things in content-centric applications (as opposed
to user-centric apps like personal calendars, etc), the chances that those apps
set the context_id of the data that he/she creates to his/her user_id (either
directly or through inheritence) is significantly lower, so the plan would likely
break down under a number of circumstances. This would be an easy but
highly inflexible hack.
Probably the most effective and clean method would be to create a new rel
type with similar semantics to the composition rel, but one that allows both
sides to be users. That would create a sort of setuid-style permissions
inheritence from the first party to the second. It's been a while since i hacked
around in the party_element_index denormalization, so it's hard to for me to
say off-hand whether this would be easy or hard, but i'd imagine it's either a 5
minute fix or a rather intense edit of some pretty complicated triggers to make
it all work. Either way, that sounds like it would be a cool feature to have.
