Moving discussion to design list since we're talking about workflows
now :)
What if it's an optional attribute like Triage status? I can imagine
a spouse pair wanting to share needs reply status for a spouse email
account. Or PPD might want to share needs reply status on design list
emails. There are scenarios for this, but not a priority for Preview
if it's tricky. There's also the scenario of 2 admins managing
requests together etc.
Thx, Mimi
Share: [ ] Triage status
[ ] Alarms
[ ] Needs reply status
[ ] Event status
On Mar 16, 2007, at 9:11 PM, Philippe Bossut wrote:
Hi,
Answering with my $0.02 since Mimi didn't.
Bryan Stearns wrote:
Grant Baillie wrote:
On 15 Mar, 2007, at 09:50, Bryan Stearns wrote:
Morgen Sagen wrote:
On Mar 13, 2007, at 10:59 AM, Grant Baillie wrote:
[?] needsReply
Anyone know about "needsReply"? Is this something we just want
for dump/reload?
It's a flag manipulated by the user (by clicking in the
communications state column in the dashboard, which cycles
through read/unread/needs-reply states, manipulating the "read"
and "needsReply" attributes. Yes, it should be dumped and reloaded.
Should it be shared (i.e. supported by Cosmo, too)?
I don't know the answer to that - Mimi, should the needs-reply
state be shared?
I think that needsReply shouldn't be shared since it's a user local
decision (shouldn't influence anyone else decision on replying or
not...), like "read/unread" (with which it is bundled from a UI
standpoint).
So same treatment as read, i.e. not shared but dumped and reloaded
(that's an [X] if I understood Grant's code correctly).
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
