On Apr 26, 2007, at 8:02 AM, Mimi Yin wrote:
Hi Morgen,
Thx for writing this up!
Can we have all of the filters checked in the Desktop for both
publishers and subscribers, except for BCC and Needs reply?
Yes
And can we remove the sharing filters from the Subscribe dialog and
instead have subscribers find them in the Manage share dialog?
I don't quite follow why you would want to remove the filter
checkboxes from the subscribe dialog, but yes I can take them out.
In our small workgroup usage scenarios, I think most people will
want to share Triage Status / Alarms and Event Status.
1 - A shares A's personal Work collections with B. B wants to see:
+ Whether A is confirmed to go to an appointment or not,
+ What A is working on NOW versus what has been deferred,
+ Won't be setting personal alarms on A's tasks and events.
2 - A shares a group Project collection with B,C and D.
+ Everyone wants to see if any given event is confirmed or not.
+ Everyone wants to see what the group is working on NOW versus LATER.
There are going to be cases that won't be met by our "per-item
triage status/alarm and event status" model.
Subscribers can't add shared events to their personal calendars and
set personal alarms, event status or personal triage status,
independent of the group without losing the group's TS, alarms and
event status.
Post-Preview, we should revisit this issue and see how badly users
need to have per-person values for TS, alarms, and event status.
https://bugzilla.osafoundation.org/show_bug.cgi?id=8927
Other Post-Preview issues include:
+ More robust distinction between sharing with myself (keeping
multiple machines in sync) and sharing with others (For Preview, we
should encourage users to send .ini files to themselves when
sharing with themselves.) https://bugzilla.osafoundation.org/
show_bug.cgi?id=8928
+ Presenting Subscribers with the list of sharing filters the
Publishers would *like* to share with them. https://
bugzilla.osafoundation.org/show_bug.cgi?id=8929
+ Ability to type collections? Personal collections versus Group
collections. https://bugzilla.osafoundation.org/show_bug.cgi?id=8930
A few questions about allowing subscribers to edit read-only shares...
+ Could this be viewed as an annotation feature? User makes local
edits that don't get synced to the server?
Well, to be precise, this is not annotating but rather overriding.
You are replacing an "external" value with your own -- one that
doesn't get sent to the server. You could imagine the read-only
subscriber adding notes to an event's body and think of that as
annotation, but really the subscriber is modifying their private copy
of the body. If someone else later changes the body, the read-only
subscriber will see a conflict; they can discard the conflict, but at
least they are made aware whenever someone else changes that body.
+ Does this feature apply to read-write shares as well?
Well, in read-write shares, local changes that aren't being filtered
out *are* synced to the server, so it's not really the same. The
only conditions in which a local change is not sent to the server is
if the field is being filtered out or if the local change is in
conflict with what's on the server.
+ Can all attributes can be annotated?
The sharing framework puts no restrictions on which fields can be
overridden by a read-only subscriber. Note I am using the term
"fields" instead of "attributes". The EIM-based framework doesn't
know about Chandler "attributes" per se. If you want to restrict
what UI-visible values the user can modify, that needs to be handled
at a level "above" the sharing framework, in the UI itself.
+ Can you make destructive annotations? ie. Change the start-time.
The sharing framework allows the read-only subscriber to override any
field. Again, if we want to put restrictions on which ones the user
is allowed to modify, that needs to now happen in UI code.
~morgen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
