I understand that we want to keep (some!) end-users' mental-maps
simple. But we don't have to do that in a way that makes Cosmo less
useful and cripples an existing spec (the tickets spec).
Just because one particular client (Chandler Desktop) doesn't ever
want to know about more than those tickets doesn't mean we should
make it so that no one else can us Cosmo that way if there are other
ways around it. Why not have some metadata on the tickets which says
"these are the Chandler Desktop Tickets" or something?
On Nov 13, 2007, at 2:58 PM, Mimi Yin wrote:
Hi Bobby,
We don't currently have end-user UI to revoke tickets. For the
Desktop, the way you deal with the use case your describing is to
unpublish a collection, republish it and hand out new tickets.
We could add a 'Generate new pair of URLs' button to the Web UI so
that Hub-only users could do the same.
In the meantime, the proposal is to keep the end-user mental model
re: tickets as simple as possible and save our energy for
implementing real ACLs :)
Mimi
On Nov 13, 2007, at 2:32 PM, Bobby Rullo wrote:
Mimi,
I have reservations about the "2 tickets per collection" proposal,
and the discussion linked to in bug 11320 doesn't seem to be the
right one.
In the absence of ACLs, allowing different tickets for different
people (or groups of people) is the next best thing.
Consider the case of a small organization using Cosmo for a shared
calendar. What if one of those people left, and you no longer
wanted them to have access? If you gave that person their own
ticket, you could revoke that particular one.
I'd rather not see us take away a feature from the server to make
the design of the client easier. Also, this is a proposal that
should be discussed on the Cosmo list as well, or at the very
least tagged with '[cosmo]' on design.
Bobby
On Nov 13, 2007, at 1:29 PM, Mimi Yin wrote:
Bobby,
https://bugzilla.osafoundation.org/show_bug.cgi?id=11320 will
move us to a 2-ticket per collection model.
Mimi
On Nov 13, 2007, at 1:14 PM, Bobby Rullo wrote:
What if there are multiple (more than just one read, and one
read-write) tickets issued to that same collection?
Maybe the Sharing tab needs to be more of a full-fledged Ticket
Managent tab....
bobby
===
Tab: Share
-----
Give out the URL(s) below to invite others to subscribe:
View-only: http://hub.chandlerproject.org/xxxxx <LINK>
View and Edit: http: //hub.chandlerproject.org/xxxxx <LINK>
this implies that tickets are automatically created when a
collection
is created. this is true when a collection is created with
Morse Code
(i.e. by Desktop), but it's not true when somebody creates a
collection through the web UI or DAV (iCal, command line). i don't
have any problem making that happen, though.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
