Can't close a particular item in the alarm-notify list

Thank you for your bug. What version of Ubuntu do you use? Could you describe easy steps to trigger the bug?

I am using Feisty Fawn

$ uname -a
Linux lap432 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

To trigger the bug follow these steps.
- Add two appointments to the evolution calender maybe at different times but arrange the alarm timings such that they pop up at the same time (e.g. at 8:30 AM add appointment at 9 AM and 9:45 AM. Set alarm for 9AM appointment to 15 minutes before the appointment and set the 9:45AM appointment's alarm to 1 hour before the appointment).
- So at 8:45 AM both alarms are shown.
- Suppose you want to close only the first appointment's alarm then it is not possible.
- Workaround is to snooze the second (or n-1) appointments' alarms and then close the remaining alarm.

Provided the necessary info

No feisty for me, so test this on evo 2.11.90/e-d-s 1.11.90.

I cannot reproduce it on 2.11.90/1.11.90. I am able to close one single alarm (by selecting snooze for the others), or all of them, or none.

Well, the functionality I am expecting is,
"without having to snooze other alarms I should be able to close a single alarm"

I am using evolution 2.10.1 (what is e-d-s?)

This functionality will be similar to that of MS Outlook where you can selectively dismiss reminders without having to snooze remaining reminders.

Let me know if you need any other info

@Amit: e-d-s is Evolution Data Server. What we normally call Evolution is actually a collection of sources and distribution packages (Evolution, Evolution Data Server, Evolution Exchange, the libraries, etc).

I do not have Feisty available for testing (in fact, I do have two servers running Feisty, but I am not going to install Evo there), so all I can do is verify if your problem is present in in up-to-date Evo. As I stated, it does not seem to -- per my initial understanding of your bug.

Rereading your last comment... it seems what you want is to: given a collection of triggered alarms, select a subset and close this subset; this action would then (implicitly) renew the rest of the collection for another round.

OTH Evolution seems to do it the other way: given a collection of triggered alarms, select a subset to be re-triggered; this action would then (implicitly) close the rest of the collection. This behaviour is similar to the one Lotus Notes uses.

Regarding your following comment,
<snip>
Rereading your last comment... it seems what you want is to: given a collection of triggered alarms, select a subset and close this subset; this action would then (implicitly) renew the rest of the collection for another round
</snip>

I am not expecting the 'rest of the collection' to implicitly renew (I guess you mean snooze here). Instead I want it to remain there in the alarms list dialog box and don't want it to vanish for x amount of time (which will happen by clicking snooze).

You might understand what (or why) I am asking (this) after knowing my way (or a group of users' way) to to handle this (alarms) feature.

When a set of alarms pop up in a list, I usually prefer the list to remain in the dialog (instead of snoozing after every x amount of time) and close selective items as and when the work related to that item is finished. Currently I have to snooze all the unfinished items to close the targeted item.

So in short the feature requested is "I don't want to snooze any of the items but close only selective items and the remaining items should persist in the dialog till I close them (instead of getting vanished for some time by snoozing them).

It might seem rather personal/unnecessary feature and you can close this request if you are not convinced to buy this idea.

Let me know what you think.

Thank you for the clarification. I do agree with your way (I think :-), and it makes sense. I noticed it, but did not pay enough attention, sorry: when I select any alarm, the dialog is closed. It should instead remain -- as long as there are other alarms displayed to act on.

Hum. I will look upstream as soon as I have a chance (or, otherwise, someone else may do it -- I am quite busy right now earning a living ;-). I am setting this bug as Incomplete, but it is actually to go to Triaged & checked upstream.

Searched upstream, did not find any hits, so opened a new upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=504255.

change status to Fix released (see gnome-bugs)