upgrade following to use sets

Ticket

+commit
 

Current following (aka "watching") has many problems:

 

  • by organizing into +*watcher cards, the permissioning is very limited (hard to make it so that you can edit your own followed cards but not others')
  • can't follow sets other than self and type
  • groups can't currently follow cards
  • there is special card_controller handling that breaks MoVE principles
  • the code is pretty messy

We also want to be able to do the following (which are covered in other tickets):

  • show the actual changes (not just the fact that it has changed.  (I hear this a LOT)
  • customize the message surrounding the change

Separately, we want folks to be able to control the frequency of their following emails (eg, in a digest).

 

 

 

(accounted or role)+*following cards are pointers, and items in pointers can be sets.

 

(accounted or role)+*following+*frequency determines frequency of emails (defaults to immediate)

 

interface needs:
  • better set labels
  • some way to get to frequency setting
I thought of a different way to handle the interface:
 
follow/unfollow
- follow (self set)
- follow (set 2...)
- follow (all)
 
- see all followers
 
add "following" to account menu.
- following list (on account cards)
 
 
 
 
Following email guideline proposal
 
First, we need this concept of "field descendants"  (I would love a better term).  I'm suggesting something like this:
  • A+B is a child of A and B.
  • A+B is a field of A (but not of B)
  • A+B and A+B+C are descendants of A and B
  • A+B and A+B+C are field descendants of A (but not of B)
 
  1. There should only be one email per user per card_act (as card_act is defined here: track name and type changes )
  2. The card that is the subject of the act should be the one mentioned in the subject of the email.  Eg, if I'm watching all +B cards and you update A (A is the one "acted upon") with changes that include updates to A+B, then I should be notified, but the subject should mention that "Philipp updated A".
  3. The content of the email should be a collection of all followed changes.  I'm using the definition of changes in that same ticket, and  where a followed change includes:
    • changes to a followed card (one that is a member of a set referred to in a +following card)
    • changes to a "field descendant" (see above) of a followed card.