Alarms fetched in Alarms API are getting their date from the due date, which is the due date of the next occurrence. The question is whether I get a proper date at fetch time if I do not set the due date for the original event. Or is the due date for the individual occurrences set independently from the original event's due date? If yes, we can make the change in UITK Alarms API.
-- You received this bug notification because you are a member of Unity API bugs, which is subscribed to Indicator Date and Time. https://bugs.launchpad.net/bugs/1283859 Title: Updated recurring alarm values are not reflected in the indicator until phone reboot Status in The Date and Time Indicator: New Status in Clock application for Ubuntu devices: Confirmed Status in Ubuntu UI Toolkit: New Status in “qtorganizer5-eds” package in Ubuntu: New Bug description: Mako 205 Steps to reproduce: 1. Create a recurring alarm and save it 2. Select the saved alarm to go to edit mode 3. Change the time or day of the alarm 4. Hit save What happens: The alarm is correctly updated in the clock app. The indicator however still shows the old alarm time What should happen: The alarm is correctly updated *both* in the clock app and the indicator. If you however reboot the phone, the indicator then shows the updated recurring alarm time. To manage notifications about this bug go to: https://bugs.launchpad.net/indicator-datetime/+bug/1283859/+subscriptions -- Mailing list: https://launchpad.net/~unity-api-bugs Post to : [email protected] Unsubscribe : https://launchpad.net/~unity-api-bugs More help : https://help.launchpad.net/ListHelp
