On 2/9/07, Mimi Yin <[EMAIL PROTECTED]> wrote:
Question: Why would someone want/need to create a group to grant privileges? Is it so you can easily give the same group of people access to different shares?
this feature is more important for structured environments where security is more important than it is in our casual collaborator world. imagine somebody running cosmo inside a bank, with complicated security policies determining which information each individual department can access.
Workflow question: Can you create a group after you've granted privileges to a whole list of individuals.
theoretically yes, but in practice i've never seen anybody do that.
What about query-based groups? Are these static or do they refresh? Can you have inclusions and exclusions? Everyone with a username that starts with a letter from A-M + this user who has a username that starts with '!' What are use cases for this? Is this mostly an admin feature?
i don't think most people would use these capabilities.
How often will users create short-lived shares?
who knows. it seems like a usage that is supported by definition for which we don't need to go out of our way to do anything special.
A twist on the tour group example. Say you work with the same travel agency, but the visitors themselves change. Would you want just a single group and then change the tour group members out every week? Or would you want one group for the travel agency people and then create a new group for each tour group every week?
the latter.
Workflow question: Can you create accounts for the tour group visitors as you populate the group? And then send the accounts + passwords to the members of the tour group, at which point they can change their password? As an organizer, it seems like you would want to do that, rather than waiting for the individuals in the group to create their accounts before assigning privileges one-by-one.
i'd probably want to define an empty group with a particular privilege set and then go register accounts for each member, assigning the member to the group as i enter his other details.
2. There will presumably be students who haven't yet signed up for an account? Using email addresses seems like it would cover both users with accounts and those without accounts.
i think what he meant was using a group as a sort of contact list. because cosmo has an email address for every user account, it can create an ad hoc mailing list for every group of users+groups.
3. How do privileges interact with tickets? What about per-user tickets?
if a person has logged into cosmo, then he can access a collection either by having an acl on the collection or by having a ticket for the collection. if he presents a ticket and doesn't have an acl, he gets in. if he has an acl and doesn't present a ticket, he gets in. if he has both, he gets in. if he has neither, he doesn't get in. if a person has not logged into cosmo, then he can only access a collection by having a ticket for it. the concept of "per-user" ticket doesn't really mean anything. a ticket is valid for anybody who holds it.there's no mechanical difference whether you give a ticket to one person, many people, or no people. if you were to somehow restrict a ticket so that it was only useful for an individual user, and that user had to be logged into cosmo in order for the ticket to be accepted, then there would be no practical difference at all between a ticket and an acl. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
