You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 20, 2017. It is now read-only.
some engagements, involving key leaders are to be tracked differently
key leaders could have a position in any organization that otherwise hosts advisers
Still-fuzzy areas
Although it may be rare, KLs could potentially take part in engagements that are advisory/non-KLE
There are key leaders among the principals as well. It seems though that the determination of if an engagement is KLE should be driven by adviser side
Proposed approach
Add the ability to specify if a position is a KL position. The seemingly least db-intrusive way is to add a KEY_LEADER PositionType and not create a new DB column. The downside is that 1) from there on a SUPER_USERs and ADMINISTRATORs will need to be implied to be privileged ADVISORs and not KLs and 2) The KEY_LEADER nature can't be set on a principal position. The alternative is to add an independent db field. As 1) is very unlikely to be a problem and 2) is not an information that can be exploited at this time, I suggest to go ahead with the simple approach.
Add the ability to determine if an engagement is a KLE. I propose to start with a simple rule - if a KL is an attendee (or maybe a primary) of an event, it is a KLE event. It can be discussed how this rule can be stored in the DB for abstractness reasons. A future enhancement, if needed at all, could be to make all engagements without a KL automatically advisory engagements and when a KL is present provide a choice.
Update rollups to not count KLEs against organization statistics, but to aggregate them in a KLE category.
Thoughts?
The text was updated successfully, but these errors were encountered:
Initial requirements:
Still-fuzzy areas
Proposed approach
Thoughts?
The text was updated successfully, but these errors were encountered: