[chandler-users] #7894: not "purged" to the DONE section

Mimi Yin mimi at osafoundation.org
Fri Feb 8 15:29:33 PST 2008


Agreed Davor. What we have right now isn't the desired behavior, but  
merely the result of needing to stage the complicated triage logic work.

The behavior you would like is logged as bug: https:// 
bugzilla.osafoundation.org/show_bug.cgi?id=10557

It's helpful to know that you noticed! Mimi

On Feb 8, 2008, at 3:02 PM, Davor Cubranic wrote:

> I should point out a related problem with changing item status, a sort
> of reverse of this bug: it appears that if I ever set an item's status
> manually, Chandler will never modify it automatically, regardless of
> alarms and due dates.
>
> Example: I had an any-time item that was set to Wednesday. I didn't
> finish it at the end of the day, so I moved it to Friday. Its status
> remained NOW (perhaps I set it manually somewhere along the way), so I
> set it to LATER myself. When Friday rolled along, the item's status
> remained LATER.
>
> I don't think this is a desirable behaviour. Even if I have set the
> item's status manually to NOW, once the item has been moved to the
> future, the status should be changed to LATER. Similarly, even if I  
> set
> the status to LATER, it should pop to NOW on the due date.
>
> Davor
>
>
> On Fri, 8 Feb 2008, Mimi Yin wrote:
>
>> Hi Rick,
>>
>> Hm, triaging an item to DONE until a future alarm date fires is  
>> *supposed* to work.
>>
>> I wonder if you are experiencing one of the many pop-to-now bugs  
>> we've been trying to track down over the last few months: http://  
>> chandlerproject.org/Planning/OneDotZeroWorkQueue#PopToNowBugs
>>
>> It would be interesting to know if you can reproduce this  
>> situation with items that aren't on the server.
>>
>> Mimi
>>
>> On Feb 8, 2008, at 1:42 PM, Rick Rawson wrote:
>>
>>>> The bugs fixed in this release include:
>>>> #7894 Events should be marked as DONE when end-date/times roll  
>>>> by, but not 'Purged' to DONE section
>>> I think I am seeing, perhaps, an unwelcomed sequela of this bug  
>>> fix. Today is 2/8. I have a task that was dated 2/11 (date in the  
>>> traige table) and a tickler set for 2/11, but which I  
>>> accomplished early. I set the triage status to DONE, patted  
>>> myself on the back, clicked TRIAGE, and watched that task get  
>>> moved to the DONE section. Then I SYNCed.
>>> That task came back, still marked as DONE, but now located in the  
>>> NEW section. The only action that prevented this from happening  
>>> was changing the tickler alarm from 2/11 to 2/8. I can understand  
>>> why Chandler might mark tasks/events as DONE if the end-date/time  
>>> rolls by, but it seems that UNTIL the end-date/time rolls by,  
>>> Chandler still considers the task/event NOT DONE, regardless of  
>>> the triage status. I suppose, logically, Chandler is asking HOW  
>>> CAN IT BE DONE?, if the completion date is still in the future.  
>>> There seems to be a conflict between logic and reality.
>>> Rick
>>> P.S. Substituting LATER for DONE in the above description changes  
>>> nothing. I tried that, too.
>>
>> Which do you mean by 'changes nothing'? The weird behavior you see  
>> above is the same regardless of whether you triage the item to  
>> DONE or LATER. Or substituting in LATER doesn't produce the weird  
>> behavior?
>>
>>> _______________________________________________
>>> chandler-users mailing list
>>> chandler-users at osafoundation.org
>>> http://lists.osafoundation.org/mailman/listinfo/chandler-users
>>
>> _______________________________________________
>> chandler-users mailing list
>> chandler-users at osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/chandler-users
>>
> _______________________________________________
> chandler-users mailing list
> chandler-users at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/chandler-users



More information about the chandler-users mailing list