Principals & Groups

---

Table of Contents

• parts of this page
  • # Example Use Cases
  • # Overview
  • # Feature List
  • # Engineering Reality

• other resources
  • Contacts Design
  • Sharing Design
  • Security Design
  • Item Projects.Collections
  • Jungle.SchemaNov2003Questions

---

Example Use Cases #

These are just a few example use cases, to give a feel for the topic. This is not meant to be a comprehensive list.

When	Use cases
Canoga	I create a new group of contacts. (Examples of groups might be "friends", "family", "soccer team", "museum committee", etc.)
Canoga	I add a contact to a group.
Canoga	I send email to everyone in a group.
Canoga	I use a group as an IM buddy list.
Canoga	I print a phone list with phone numbers for everyone in a group.
Canoga	I give everyone in a group read-only access to my calendar. (See also: CanogaSharingDesign20040419)
Canoga	I give everyone in a group read-write access to my contact list.
Canoga	I create a a group of contacts for my TAs (teaching assistants). I share my class calendar with my TAs. I add a new person to the TA group, and the new person automatically has access to the class calendar.

---

Overview #

Terminology

---

Feature List #

Category	When	Feature	Description
content model	Canoga	contacts have principals	In the content model, any contact item can have an associated principal item, which is used to store sharing information. The additional info will include a Chandler sharing address, as well as things like lists of permissions you've granted that contact, and items you've shared with that contact.
content model	Canoga	list of contacts	A group contains a list of contacts.
content model	Canoga	contact in many groups	A contact can be in more than one group.
	Post-Canoga	sub-groups	A group can contain other groups (as sub-groups).
	Post-Canoga	nested sub-groups	A group can contain sub-groups, and those sub-groups can contain more sub-groups, and so on.
	Post-Canoga	multiple super-groups	A group can be a sub-group of more than one group.
content model	Canoga	only contacts	A group can contain only contact items and other group items.
content model	Canoga	groups are content items	"Group" is a sub-kind of "Content item", which means that you can do things like put a group in a collection, assign a group to a project, and have notes or conversations contained in the group.
content model	Canoga	specific email addresses	For each contact in a group, if the contact has more than one email address, the user can specify which of the email addresses should be used in the context of this group, and the data structure representing the group can know/remember which of the email addresses to use when sending email to the group.
content model	Canoga	specific sharing addresses	For each contact in a group, if the contact has more than one principal item, the group can know/remember which of the principal items should be used when sharing things with the group.
content model	Canoga	specific IM addresses	For each contact in a group, if the contact has more than one IM address, the group can know/remember which of the IM addresses should be used when using the group for IM (e.g. using the group as a buddy list, so that I can see the presence info for people in the group).
content model	Canoga	specific contact sections	For each contact in a group, if the contact has more than one contact section, the group can know/remember which of the contact sections should be the primary section representing the contact in that group.
content model	Never	dynamic groups	You cannot make "dynamic" groups, where membership in the group is determined by a query.
cognitive model	Canoga	groups = collections	The user is aware of differences between collections and groups. In the manual, and in the user's cognitive model, there are two separate concepts. You may or may not be able to use groups in many of the same ways you use collections. We'll resolve these UI design issues on a case-by-case basis: Can you put a group in a sidebar tray? (Probably) Can you bookmark a group? Can you add a contact to a group by drag-and-drop? Can you add a contact to a group by changing an attribute on the contact?
cognitive model	Canoga	groups = organizations	A group is different from a contact that represents an organization. A contact like "Eastside HMO" can be flagged as being an business or organization, by setting an "is company" attribute. That doesn't make the "My HMO" contact into a group. You can have a group called "Doctors in my HMO", but that group has no special relationship to the "Eastside HMO" contact. You cannot take a contact and use it as a group, or turn it into a group. If you have a Contact for "The Ewing Family", you can't then use that as a group and add Mary and Bo to the group.
actions on groups	Canoga	sharing a group	You can share a group. For example, you can create a group called "People in my department at work" and then share that group with your spouse. This needs some further thought. This might be tricky to do
actions on groups	Canoga	converting a collection	You take a collection of contacts and convert it into a group, but it is only possible to do this manually (for example, perhaps by dragging and dropping all the contacts from the collection into the group).
actions on groups	Canoga	converting a group	You can take a group of contacts and somehow convert it into a collection. There will be some UI affordance for this.
actions on groups	Canoga	groups behave like contacts	You can use a group in many of the same ways that you use a contact. You can send mail to a group (although we're not trying to make groups behave exactly like mail aliases, or be a substitute for them). You can see a history of the mail you've sent to a group. You can share something with a group. You can add the members of a group to your IM buddy list and see their presence info.
sharing id	Open Issue	Sharing ID	Will we have a unified namespace for IM and sharing? Is my "sharing id" the same thing as my IM id? We will resolve this as part of CanogaSharingDesign20040419
sharing id	Open Issue	Sharing ID	Can a Contact have more than one sharing id? For example, a "home" address and a "work" address. We will resolve this as part of CanogaSharingDesign20040419
	Open Issue	Unique addresses?	What if two contacts share the same email address? Do we mandate that two contacts can never share the same email address? Jabber ID? But same phone number is okay? We will resolve this as part of CanogaSharingDesign20040419
	Open Issue	selecting an address	How do we select which communication channel in a Contact (IM, email, sharing) when there are multiple options (e.g. Jim home, Jim work, Jim beach house on Martha's Vinyard, Jim's account-for-travelling)? We will resolve this as part of CanogaSharingDesign20040419
	Westwood	LDAP integration	LDAP integration
content model	Canoga	no "public" principal	There is no principal or contact called "public" or "world" or "everyone". Maybe you can share an item with everyone in the general public, but you can't go look at some "public" principal and see what items you've shared with "public".
permissions	Canoga	group permissions	When you share an item with a group, we associate the shared item and access permissions with the group itself, not just with each of the principals in the group.
permissions	Open Issue	resolving multiple sharing policies	Let's say you share calendar "Foo Cal" with group "Bar Group" using sharing policy A (e.g. read-write), and then you also share "Foo Cal" with the principal "Ziggy", with sharing policy B (e.g. read-only). If "Ziggy" is a member of "Bar Group", what sharing policy applies to "Ziggy"? Option 1 is to use just the sharing policy that you explicitly set for Ziggy, policy B. Option 2 is to use the most permissive union of the two policies.
	Canoga	@@@	...
	Canoga Waitlist	@@@	...
	Post-Canoga	@@@	...
	Open Issue	@@@	...
	Westwood	@@@	...
	Never	@@@	...
	Already done	@@@	...

---

Engineering Reality #

How should we model all this in the pack files and parcel.xml files?

Right now we have a Kind for "Contact" up in the contacts parcel.xml file, in .../parcels/OSAF/contentmodel/contacts. But I'm guessing that's not where we're going to want to keep track of principals and access permissions. The repository code is going to have to be hard-coded to know about principals and access permissions, but it shouldn't have to know about the Contact Kind up in the end-user content model. Seems like we might want to have a Kind called "Principal" down in the core schema. But then how do we connect that with the notion of a Contact?

---

---

Meeting notes from 23 Feb 2004 Users & Groups design meeting

Attending: AndiVajda, TedLeung, HeikkiToivonen, BrianDouglasSkinner, MitchKapor, ChaoLam

Next meeting:

• at noon on Wednesday, 25 Feb 2004
• rescheduled for Tuesday, 16 March 2004, 2:45 to 4:15
• rescheduled for Monday, 15 March 2004, 1:00 to 2:30 -- see notes

Resolution about Layering:

[Resolution] We should have three distinct layers in content model, like this:

component layer	content model layer	examples of kinds in each layer
Repository	Core data model	Attribute Type Kind Principal Permission Group
Chandler core	Core content model	Content Item Item Collection (playlist) Project
	???	Calendar event? Mail message? task? Contact? Note?
PIM capplet	PIM content model	???

Open Issues about Layering:

• [Action Item] We need to go through the existing content model and think about which kinds belong in the Chandler core. We should refactor the content model and pick a good separation between (a) Chandler core content model and (b) PIM content model.

• [Open Issue] What kinds should be included in the Chandler core? Mitch suggests we consider these kinds:
  • File -- a Chandler item that has an attribute that points to an old-fashioned file in the OS file system, like a spreadsheet file or a MS Word doc
  • Conversation -- a Chandler "Conversation" item, attached to a Content Item
  • Note
  • Contact
  • Mail Message
  • IM

Other Resolutions:

1. [Resolution] In the Users And Groups Design doc, we should use the term "principal" in the place where we had originally used "user".
2. [Resolution] We should have a kind called Principal. A principal represents another Chandler user who you share content with. In the cognitive model of the person using Chandler, a contact and a principal will usually be identical. In the content model, the Principal Kind will have attributes that keep track of some sort of identity or authorization information (maybe in the form of a username and password, or maybe in the form of some sort of certificate or encryption key). A principal item might also have an attribute that points to all the access permissions that I've granted to this principal.
3. [Resolution] Each contact in my address book will typically have at most one associated principal item, although some contacts might have more than one principal item (for example, in my "Sara" contact I might have a "Sara at home" principal and a "Sara at work" principal).
4. [Resolution] There should be a many-to-many relationship between Contacts and Principals
5. [Resolution] The Principal kind should be defined in the Repository layer, as part of the core data model.
6. [Resolution] The Contact kind should not be defined in the Repository layer, as part of the core data model.
7. [Resolution] The Contact kind should be a sub-kind of Content Item.
8. [Resolution] The Principal kind should be a sub-kind of Item, not Content Item.
9. [Resolution] A principal can "contain" sub-principals.

Remaining Open Issues:

1. [Open question] Does a Principal represent "another Chandler user who you share content with", or "a specific repository belonging to another Chandler user who you share content with"? If I want to share my calendar with Chris, and Chris has Chandler installed at home and at work, do I share my calendar with "Chris", or with "Chris at home"? At which level do we associate the access permissions? Do we do automatic sync with one repository or with both? At which level do we keep track of what items need to be refreshed?
2. [Open question] If a Principal item really represents "a specific repository belonging to another Chandler user who you share content with" rather than "another Chandler user who you share content with", then should we use some word other than "Principal"? Maybe something like "Foriegn Repository"?
3. [Open question] In the user's mental model, we have Contacts and Groups. A group can have many contacts in it. A contact cannot have any other contacts in it. In the repository layer we just have Principals, where any principal can have sub-principals. How do we reconcile those two models?
4. [Open question] Should there be a kind called "Group"?
5. [Open question] Is there a 1-to-1 relationship between Group and Principal (each Group is a user-level representation of a repository-level Principal)?
6. [Open question] Can we say that Group will be defined in the same layer at Contact?
7. [Open question] Can we say that Group will be a sub-kind of Content Item?
8. [Open question] Should we have a kind that represents an "access permission"?
9. [Open question] Can an "access permission" be given just for Content Items, or to other types of items as well?
10. [Open question] Should we have a kind that represents an "X.509 Certificate"? Or maybe a Type instead of a Kind?
11. [Open question] Does each Principal have an X.509 Certificate?
12. [Open question] Is there a notion of a "me" Contact? How is that modeled? Is there a notion of a "me" Principal?
13. [Open question] Let's say I have a two computers, one at work and one at home, and each one has it's own copy of Chandler and it's own repository. I can share items between them using normal sharing. Is that sort of sharing just like sharing between any two repositories, or is it somehow different? Do these two repositories "know" that they belong to the same "me" Contact, or the same Principal? Do they automatically transfer Certificate info for the Principals of other people they share with?
14. [Open question] What are the attributes of a Principal?
    • one or both of the following
      • a list of sub-principals of this principal?
      • a super-principal of this principal?
    • a list of access permissions granted to this principal?
    • one but not both of the following:
      • a list of Contacts that this principal is associated with?
      • a single Group that this principal is associated with?
    • a notification queue, which has a list of items (or a list of changes to items) that need to be transmitted to the foriegn repository whenever we can next connect to the foriegn repository
    • a connection address, so that we know how to find the foriegn repository and start a conversation with it (should this really be a list of addresses, some of which might use different routes or transports?)
    • an X.509 Certificate that we got from the Principal, with
      • a "verfied" bit, which is true iff we have exchanged thumbprints to confirm the X.509 Certificate
      • a "trusted" bit, which is true iff the Certificate was created by a CA that we trust
      • a "revoked" bit, which is true iff this Certificate has been revoked or expired
    • a note about which X.509 Certificate we gave to the Principal, with
      • a "verfied" bit, which is true iff we have exchanged thumbprints to confirm the X.509 Certificate
      • a "revoked" bit, which is true iff we have revoked this Certificate
    • a revokation queue, which might have a Certificate in it if we need to revoke our Certificate whenever we can next connect to the foriegn repository
15. [Open question] What are the attributes of a Contact?
    • can we agree that a contact will look like this?
16. [Open question] What are the attributes of a Group?
    • exactly one Principal associated with this Group
    • a list of the sub-Groups in this Group
    • a list of the Contacts in this Group
      • and, for each Contact in the list, we optionally keep track of
        • which phone number within the Contact is the chosen phone number
        • which email address within the Contact is the chosen email address
        • which Principal within the Contact is the chosen Principal
        • which IM address within the Contact is the chosen IM address
        • which Contact Section within the Contact is the chosen Contact Section
17. [Open question] What does a "connection address" or "sharing address" look like? How do we find the foriegn repository and start a conversation with it?

---

Contributors

• BrianDouglasSkinner - 16 Mar 2004

---

---

Meeting notes from 15 Mar 2004 Users & Groups design meeting

Attending: AndiVajda, HeikkiToivonen, BrianDouglasSkinner, MitchKapor, KatieCappsParlante, ChaoLam, MimiYin, Scott, Lisa, TedLeung (by phone)

Previous meeting:

• 23 Feb 2004 -- see notes

Terminology Resolutions

Warning: Can't find topic Trash.SharingGlossary

Warning: Can't find topic Trash.TrueSharing

Resolutions

1. [Resolution]
   • Q: Does a Persona+ represent "another Chandler user who you share content with", or "a specific repository belonging to another Chandler user who you share content with"?
   • A: If a Contact has only one Persona+, then you can think of the Persona+ as representing "another Chandler user who you share content with".
   • A: A Contact can have two or more Personas+, where each Persona+ represents "a specific repository belonging to another Chandler user who you share content with". For example, my Contact item for Chris might have two Personas+, one for the "Chris at home" repository and one for the "Chris at work" repository.
   • A: If Mary has just one Repository, and Mary uses Replication to keep two copies of it in sync, at work and at home, then in my address book my Contact for Mary will have just one Persona+
2. [Resolution]
   • Q: If I want to share my calendar with Chris, and Chris has Chandler installed at home and at work, do I share my calendar with "Chris", or with "Chris at home"?
   • A: This will work just the same way that people use email today. If Chris has two repositories, Chris might give me just the address of one repository (in which case I share with that one), or Chris might give me the address of both repositories and then tell me what she uses each one for and explain when I should share things with one versus the other.
3. [Resolution]
   • Q: At which level do we associate the access permissions? Do we do automatic sync with one repository or with both (e.g. "home" and "work")? At which level do we keep track of what items need to be refreshed?
   • A: We associate access permissions with a Persona+, not with a Contact. We keep track of items that need to be refreshed on a per-Persona+ basis, not on a per-Contact basis. We do automatic sync just with the one repository associated with the Persona+ we shared with.
4. [Resolution]
   • Q: If a Principal item really represents "a specific repository belonging to another Chandler user who you share content with" rather than "another Chandler user who you share content with", then should we use some word other than "Principal"? Maybe something like "Foriegn Repository"?
   • A: Yes, we should use a different term. We couldn't think of a good term, so for now we're going to use the term Persona+.
5. [Resolution]
   • Q: In the user's mental model, we have Contacts and Groups. A group can have many contacts in it. A contact cannot have any other contacts in it. In the repository layer we just have Persona+, where any Persona+ can have sub-Persona+. How do we reconcile those two models?
   • A: In the repository-level data model, we may want to introduce the notion of a Repository-Group, which would be a type of Persona+. If so, then only Repository-Groups would have lists of sub-persona+, and Persona+ would not have sub-Persona+. But that's just one solution. We'll leave it to the repository group to decide how to do this. It may be that the repository ends up implementing some richer semantics which the Chandler app uses only some features of.
6. [Resolution]
   • Q: Should there be a kind called "Group"?
   • A: Yes. (And maybe a Repository-Group as well.)
7. [Resolution]
   • Q: Is there a 1-to-1 relationship between Group and Persona+ (each Group is a user-level representation of a repository-level Persona+)?
   • A: Yes. Or more specifically, there's a 1-to-1 relationship between a Group and a Repository-Group.
8. [Resolution]
   • Q: Can we say that Group will be defined in the same layer at Contact?
   • A: Yes.
9. [Resolution]
   • Q: Can we say that Group will be a sub-kind of Content Item?
   • A: Yes.
10. [Resolution]
    • Q: Should we have a kind that represents an "access permission"?
    • A: Maybe. Or maybe we want a lighter weight data structure. This is a technical design decision for the repository group.
11. [Resolution]
    • Q: Can an "access permission" be given just for Content Items, or to other types of items as well?
    • A: The design group only requires that users be able to share Content Items, Views, and Item Collections. The repository group might chose to implement a more general system in which any item can be shared.
12. [Resolution]
    • Q: Is there a notion of a "me" Contact? How is that modeled? Is there a notion of a "me" Persona+?
    • A: The end-user may have a notion of a "me" Contact, but that would be a feature of the UI and the application level code. At the repository level there are just Persona+, and the user "logs in" as one of these Persona+ (so that from the user's perspective, that Persona+ is "me" for the duration of the session).
13. [Resolution]
    • Q: Let's say I have a two computers, one at work and one at home, and each one has it's own copy of Chandler and it's own repository. I can share items between them using normal sharing. Is that sort of sharing just like sharing between any two repositories, or is it somehow different?
    • A: It's different. That's Replication, not True Sharing^?
    • Q: Do these two repositories "know" that they belong to the same "me" Contact, or the same Persona+?
    • A: Yes, they do.
    • Q: Do they automatically transfer Certificate info for the Persona+ of other people they share with?
    • A: Probably, yes.

Content Model Resolutions

• Chandler Level Data Structures
  • Contact
    • A Contact is a sub-kind of Content Item
    • Each Contact can have many Personas+ (e.g. "home" vs. "work")
    • Each Contact can be in many Groups
    • (See also the existing content model: Contact)
  • Group
    • A Group is a sub-kind of Content Item
    • Each Group can have many Contacts
    • Each Group can have one associated Repository-Group
    • (See also Remaining Open Issue #5 below)

• Repository Level Data Structures
  • Persona+
    • A Persona+ is a sub-kind of Item
    • Each Persona+ can appear in many different Contacts (e.g. just like two Contacts might have the same phone number)
    • Each Persona+ can be a member of many Repository-Groups
  • Repository-Group
    • A Repository-Group is a sub-kind of Persona+
    • Each Repository-Group can have one associated Group
    • Each Repository-Group can have many member Personas+
  • Access Permission
    • We don't yet know what data structures we want to use to associate access permissions with Personas+, Content Items, Views, and Item Collections.

Remaining Open Issues:

1. [Open question] Should we have a kind that represents an "X.509 Certificate"? Or maybe a Type instead of a Kind?
2. [Open question] Does each Persona+ have an X.509 Certificate? Or maybe more than one? Maybe one that represents the Persona-as-publisher and a different one that represents the Persona-as-subscriber?
3. [Open question] What are the attributes of a Persona+?
   • one or both of the following
     • a list of sub-Personas of this Persona+?
     • a super-Persona+ of this Persona+?
   • a list of access permissions granted to this Persona+?
   • one but not both of the following:
     • a list of Contacts that this Persona+ is associated with?
     • a single Group that this Persona+ is associated with?
   • a notification queue, which has a list of items (or a list of changes to items) that need to be transmitted to the foriegn repository whenever we can next connect to the foriegn repository
   • a connection address, so that we know how to find the foriegn repository and start a conversation with it (should this really be a list of addresses, some of which might use different routes or transports?)
   • an X.509 Certificate that we got from the Persona+, with
     • a "verfied" bit, which is true iff we have exchanged thumbprints to confirm the X.509 Certificate
     • a "trusted" bit, which is true iff the Certificate was created by a CA that we trust
     • a "revoked" bit, which is true iff this Certificate has been revoked or expired
   • a note about which X.509 Certificate we gave to the Persona+, with
     • a "verfied" bit, which is true iff we have exchanged thumbprints to confirm the X.509 Certificate
     • a "revoked" bit, which is true iff we have revoked this Certificate
   • a revokation queue, which might have a Certificate in it if we need to revoke our Certificate whenever we can next connect to the foriegn repository
4. [Open question] What are the attributes of a Contact?
   • can we agree that a contact will look like this?
5. [Open question] What are the attributes of a Group?
   • exactly one Persona+ associated with this Group
   • a list of the sub-Groups in this Group
   • a list of the Contacts in this Group
     • and, for each Contact in the list, we optionally keep track of
       • which phone number within the Contact is the chosen phone number
       • which email address within the Contact is the chosen email address
       • which Persona+ within the Contact is the chosen Persona+
       • which IM address within the Contact is the chosen IM address
       • which Contact Section within the Contact is the chosen Contact Section
6. [Open question] What does a "connection address" or "sharing address" look like? How do we find the foriegn repository and start a conversation with it?

Action Items

1. Replication
   • Mitch to own the problem of finding someone to take ownership of the replication project -- requirements, open issues, implementation options, etc.
   • Main.BrianDouglasSkinner to add this "Replication" project to the ProjectOverviewTable2005
2. Meeting notes
   • Main.BrianDouglasSkinner to write up notes from the meetings -- including resolutions, open issues, and who owns what follow-up items. (Done. You're reading it: Journal.UsersAndGroupsDesign20040315)
   • Main.BrianDouglasSkinner to create glossary terms for the different terms agreed on at the meeting. (Done, see #TerminologyResolutions above.)
3. Design doc updates
   • BrianDouglasSkinner to update the Users & Groups design doc to reflect the decisions made
   • Chao to update the Sharing design doc to reflect terminology changes and other decisions made
     • one detail that needs to change is the " What is shared?" bullet point in the Overview section. Needs to change to reflect the fact that we actually do share views, not just (an item collection with an associated recommended view type).
4. Heikki to make proposal regarding certificates
   • How many certificates are associated with each Persona+ (and each Repository)?
   • How are certificates modeled? Pros and cons of type vs. kind? How do we keep track of info like "revoked", "verified", etc.?
5. Installation Configurations
   • BrianDouglasSkinner to add this "Installation Configurations" project to the ProjectOverviewTable2005 -- (Met with Katie about this on 22 March 2004, and resolved not to create a separate project)
   • Katie to initially "own" the project, and work toward recommended resolutions of various questions, including:
     • How many copies of Chandler can one person install on one PC?
     • How many copies of Chandler can two people install on one PC?
     • Can two people who use one PC both use the same copy of Chandler?
     • When you launch Chandler, does it ask you to log in?
     • Can a single copy of Chandler be run against more than one Repository?
     • Can a single copy of Chandler be run against more than one set of UserRepositoryData?
     • In Canoga, can a single Repository have more than one set of UserRepositoryData?
6. Content Model
   • Main.BrianDouglasSkinner to write up high-level description. (Done, see #ContentModelResolutions above)
   • XXX to draft detailed content model design doc (or maybe parcel.xml)
   • Katie and/or Mitch to figure out if XXX is Katie or someone else
7. Access Control
   • Need to have some process for resolving all the things that fall in this bucket
   • Design group needs to drive design (user experience drives requirements)
   • Repository group needs to propose solution that fits with the design
   • Design group, apps group, and repository group all need to understand both the design requirements and the proposed solution.
8. Sharing
   • Need to resolve the remaining sharing issues, like the chain sharing issue. Owner? Chao?

• On Tuesday (16 Mar), after the meeting, we had a quick follow-up meeting with just Chao, Andi, Katie, and BrianDouglasSkinner. We have a few more action items that came out of that:
  • Chao to make one more revision of the access permission requirements. see CanogaAccessControlListDesign
  • Repository group to do some experimental coding work for a couple weeks, followed by some sort of informal proposal (or functional spec, or list of open issues) about the repository layer features and APIs related to personas+, access control lists, and new data model additions.
  • Content model group to make proposal offering first pass at a content model design for Groups, Contacts, etc. (Content model group is currently just Katie and BrianDouglasSkinner.)

---

Contributors

• BrianDouglasSkinner - 16 Mar 2004

---

---

Closed questions

These questions are now moot.

1. Should _User_ and Contact be two separate kinds, or a single _User/Contact_ kind?
2. If _User_ and Contact are separate, should there be a 1-to-1 relationship between them? Each instance of _User_ can point to only one related Contact and vice-versa?
3. Should _User_ be a sub-kind of Contact ?
4. Should Contact be a sub-kind of _User_ ?
5. Should Contact be a sub-kind of Content Item ?
6. Should _User_ be defined in the "Repository" layer -- in the "Core data model"?
7. Should Contact be defined in the "Chandler core" layer -- in the "Core content model"?
8. Should _Group_ be defined in the "Repository" layer -- in the "Core data model"?
9. Should _Group_ have a many-to-many relationship with _User_ ?
10. Should _Group_ be a sub-kind of Content Item ?
11. Can an "access permission" be associated with either a _User_ or a _Group_ or "anyone" (meaning "public"/"world")?
12. Can an "access permission" be given just for Content Items, or to other types of items as well?

---

Contributors

• BrianDouglasSkinner - 27 Jan 2004 to 12 Mar 2004

---

---

Comments Welcome

This is a place for posting comments. Anyone is welcome to contribute here, with any sort of comment

• Mitch, 02 Feb 2004: Jungle.CommentsOnUserAndGroups
• Questions from Chao:
  • Where is "a bit of additional sharing information attached" to user stored and displayed? as part of contact too?

---