Need a mechanism for specifying what happens when an ical menuitem is clicked

[Charles Kerr]

indicator-datetime needs a way to dispatch an arbitrary URL when a user clicks on an ical event menuitem.

In practice, datetime currently has clock-app hardwired for dispatching alarms (dispatch_url('appid://com.ubuntu.clock/clock/current-user-version')) and calendar-app for everything else (dispatch_url('appid://com.ubuntu.calendar/calendar/current-user-version')).

There are two use cases that can be supported by datetime handling the URL property <http://www.kanzaki.com/docs/ical/url.html>:

(1) Clicking on an alarm menuitem opens up clock-app to that specific alarm, rather than to clock-app's main page. Clock-app could specify the information it needs in the URL, then open the right page when passed that information later. indicator-datetime would act as a simple pass-through.

(2) non-calendar, non-alarm items such as from the reminders app as requested by mzanetti. The pattern would be the same as clock-app: Reminders would add whatever URL it wants, then datetime would act as a simple pass-through. This is preferable to adding more special cases to indicator-datetime.

See also related bug <https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1431384> which discusses abstracting out the icon shown in ical events' menuitems

[Charles Kerr (charlesk)]

Adding stakeholders to also-affects for feedback/comments

[Nekhelesh Ramananthan (nik90)]

In the description, you mentioned that "Clock-app could specify the information it needs in the URL, then open the right page when passed that information later. indicator-datetime would act as a simple pass-through." Isn't it the other way around? The use case that I see is that when the user presses on an alarm shown in i-dt, i-dt then passes the necessary information that clock app requires to identify the alarm chosen by the user to open it.

I would still need to discuss with zsombor as to what information is required by the alarms API to open a specific alarm.

[Charles Kerr (charlesk)]

nik90, what I mean is that the necessary information you're referring to would be encoded in the URL that is provided by clock-app (or by the alarm controls in ubuntu-ui-toollkit, depending on where that logic lives).

So I'd like to replace the current implentation ('url_dispatch("appid://com.ubuntu.calendar/calendar/current-user-version")') with something like 'url_dispatch(event.url)' where the url would be provided by clock/calendar/reminder and would read something like, say, 'appid://com.ubuntu.calendar/calendar/current-user-version?alarm=someAlarmId'

This would require clock-app (or the alarm controls) to add this code, but the advantage of this approach is it scales to future third-party apps as well as adding reminder to the current pool of clock & calendar.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Launchpad Janitor (janitor)]

This bug was fixed in the package qtorganizer5-eds - 0.1.1+15.04.20150508.2-0ubuntu1

---------------
qtorganizer5-eds (0.1.1+15.04.20150508.2-0ubuntu1) vivid; urgency=medium

  [ CI Train Bot ]
  * New rebuild forced.

  [ Renato Araujo Oliveira Filho ]
  * Added a new extra metadata property in collection (read-only
    property). (LP: #1347836)
  * Avoid filter or sort results if not necessary.
  * Implemented support for extended details. (LP: #1426519)
  * Optimize query by filtering collections related with the current
    query.
  * Removed missing debug.
  * Revert wrong commit.
  * Save a trigger for reminders with with secondsBeforeStart equals 0.
    (LP: #1440878)

 -- CI Train Bot <email address hidden> Fri, 08 May 2015 20:01:44 +0000

[Ubuntu Phone Apps Jenkins Bot (ubuntu-phone-apps-jenkins-bot)]

Fix committed into lp:ubuntu-calendar-app at revision 697, scheduled for release in ubuntu-calendar-app, milestone rtm14

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.