Pattern Cards+needs

Needs

• We are increasingly finding our permissioning system meeting significant limits.  For example:

  • you can set global permissions determining who can change card permissions.  Whoever can do that can change all the permissions on all the cards he/she can see.  so there's no emergent areas controlled by subgroups
  • because all permissions are set on a card by card basis, it's difficult to change permissions for a group of cards at once, like all cards of a given type.
  • because permissions are not card content themselves, they cannot be viewed and reviewed in all the flexible ways we want, so that if you want a special admin view of permissions, we have to build a special new interface.  To date this has also kept permissions out of WQL
  • there are crucial permission patterns we cannot yet support, like opening up viewing of a card to an individual user or a few individual users.
• Our formatting system is pushing up against boundaries, too, including:
  
  • lots of naming challenges.  We need different names for "tforms" and "rforms".  
  • 2-card patterns:  we would need yet another name if we ever wanted to do new formats, like "name+X" or "name+type", both of which could be handy
  • 3-card patterns: On Hooze.org we're wanting to apply automated formats to things like Timberland+Climate Counts+data, but there's no way to format "Company+Stream+data" cards.  Or for that matter, "Company+Climate Counts+data" cards, which might be formatted differently from other streams.  And if there were, would that be a tform or an rform?  I predict Meyer is going to hit this very soon, too, in virtual cards coming from Place+Topic.
  • 1-card patterns -- we often want cards not to have to follow their format.  For example, on wagn.org, I'd like to format all the cardtype cards, but I haven't because some, like Ticket, are special and I don't want them formatted that way.
• Other areas seem to be coming up where we want to follow similar patterns
  
  • We're struggling to figure out what to call *edit and *new cards, since they too might apply only to type-formatted or name-formatted cards.  The nomenclature got so awkward we considered getting rid of "*new" cards so as not to have so many.
  • still in the *edit arena, we're finding overapplication of this pattern to 1-card scenarios.  *edit instructions intended for X+A cards are showing up when editing A
  • we've wondered if we won't run across similar issues for *options, *limit, etc.