On 2/9/07, Mimi Yin <[EMAIL PROTECTED]> wrote:
Okay, let's focus on assigning privileges for now. And this would be a SNARF administrator doing this? and/or Jared/Dave as administrators of the Hosted Service?
yes for now. Later it could be even users assigning priviliges to other users or groups.
For a class schedule calendar. A professor granting read-write privileges to all his TAs. A professor granting read-only privileges to his students.
hm yeah..there will be other kind of privileges like read-acl, etc which allows a user to edit other user's permission.
It seems like these groups will stay pretty static. Although on a semester basis, the people will change. Are there scenarios where the people in the groups would change on a regular basis? Monthly,
depends on which group you are talking about. If you are talking about just a class group, the number of students will be fixed through out the semester. There will a few changes before the add deadline and after thats its almost fixed. Apart from class students a professor might have other people working under him on different projects (he is the project advisor). That will also be fixed after the add deadline. TA's will be fixed through out the semester unless the prof recruits some other TA in the middle of a semster, which could be very rare.
long as a project is going on. Once it's over, you remove them from
the user account should be deactivated and in that case they wont have any privilige. Other option is removing the account from the system and yes it will automatically get removed from the group.
Workflow question: Can you create a group after you've granted privileges to a whole list of individuals.
if you mean assigning privilege to a set of users, then making a group with those users, then automagically assign this resource to the group instead of the set of users - it is possible, but complicated. To keep it simple, I would rather create a group with those users and later assign privileges.
starts with a letter from A-M + this user who has a username that
yeah we could think of adding members based on some criteria ( a regular expression, etc).
For example, you manage a calendar for tour groups to visit Des Moines. For the week that the tour group is visiting, the tour organizers and the visitors can view and edit a shared calendar to figure out together what they would like to do.
I don't think there is a timing for the share. By default you give a privilege to a particular group, its given for the entire lifetime of the resource, unless you change it.
1. When you say adding users, do you mean adding user accounts? or email addresses?
user accounts.
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.
hm right now the implementation takes all the user or group accounts in the system. Adding users based on email addresses will be a different approach and may require creating a user, etc. To make it simple, we would mandate creation of users or groups before populating groups. A use case I can think of - users and groups can be mostly taken from a central directory server - so say if we talk LDAP we can get all the user information (which are just Cosmo accounts once Cosmo supports LDAP) and populate groups based on these accounts.
3. How do privileges interact with tickets? What about per-user tickets?
from the ticket draft: ticket transfers a limited set of access privileges on a single resource for a limited duration and limited number of accesses, if you meant, the relation between ACL and tickets - its upto us to define the relationship. As bcm suggested we could have that kind of relationship. -- Vinu In a world without fences who needs Gates? _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
