426153 - Add link to event page in event editing dialog

Status: VERIFIED FIXED

(Calendar :: Provider: GData, enhancement)

Description

[Shai Berger]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: 0.3.1

The dialog opened for editing events (or seeing event details) from the calendar has room for a link (and a button "add link"). I think it would be worthwhile, when importing events from Google, to create them with a link to the event page in Google Calendar -- at least as long as the provider does not support every single action that can be performed through the Google Calendar interface.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[klint]

This is a brilliant idea indeed... until all features are supported (SMS, mail notification,...) it would be highly useful.
Thanks

Comment 2

[Philipp Kewisch [:Fallen][☁️📆]]

Sounds like a good idea, also using the ics URL property corresponds to the correct use of it :-)

We would have to make the url field readonly though, and with this bug 382951 could possibly be fixed.

Comment 3

[Philipp Kewisch [:Fallen][☁️📆]]

Attachment: Show URL property in event dialog - v1

This should fix it, showing a "Related Link:" row in the event dialog when the URL property is set.

After fixing bug 319909, we moved from URL to ATTACH. I've noticed the problem with this is that all formerly set URLs will go away. This patch will show the URL as a "Related Link", but provide no way to remove it. This might not be ideal, but I don't think its reasonable to let the app migrate all URLs to ATTACH.

It would be nice if this bug could go in before the release, but it contains a string and would either require late-l10n or maybe be in the gray zone of "minor corrections". Thoughts?

Comment 4

[Christian Jansen]

(In reply to comment #3)
> Created an attachment (id=329802) [details]
> Show URL property in event dialog - v1
> 
> This should fix it, showing a "Related Link:" row in the event dialog when the
> URL property is set.
> 
> After fixing bug 319909, we moved from URL to ATTACH. I've noticed the problem
> with this is that all formerly set URLs will go away. This patch will show the
> URL as a "Related Link", but provide no way to remove it. This might not be
> ideal, but I don't think its reasonable to let the app migrate all URLs to
> ATTACH.
> 
> It would be nice if this bug could go in before the release, but it contains a
> string and would either require late-l10n or maybe be in the gray zone of
> "minor corrections". Thoughts?
> 

Would not be "Permalink" the correct description?

Comment 5

[Christian Jansen]

As discussed. We introduce a Menu Item called "Show Related Link" the item is located in the "View" Menu below "Toolbar".

Toolbar
----------
Show Related Link

By default the "Related Link" option is switched OFF. If switched ON a link is displayed below, Details or Attachments.

On mouse over calls a tool tip which shows the complete URL.

ui=christian

Comment 6

[Berend Cornelius]

Comment on attachment 329802 [details] [diff] [review]
Show URL property in event dialog - v1

patch works good in the calendar-event dialog. I just think that the link should be provided for the summary dialog in the same way. Currently it is displayed as an attached document. r=berend

Comment 7

[Philipp Kewisch [:Fallen][☁️📆]]

Attachment: Show URL property in event dialog - v2

A followup bug should be filed to add ATTACH links to the summary dialog. Carrying forth r+ since changes are minor and I'd like the strings in.

Comment 8

[Philipp Kewisch [:Fallen][☁️📆]]

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED

Comment 9

[Andreas Treumann]

Without a gdata calendar it is only possible to check the 'Show related link' entry, but it is not possible to uncheck this option.

Comment 10

[Martin Schröder [:mschroeder]]

(In reply to comment #9)
> Without a gdata calendar it is only possible to check the 'Show related link'
> entry, but it is not possible to uncheck this option.

Confirmed. -> REOPENED

Andreas: You should reopen bugs that are not completely fixed. Resolving as INCOMPLETE means something different (cf. https://bugzilla.mozilla.org/page.cgi?id=fields.html#status).

Comment 11

[Philipp Kewisch [:Fallen][☁️📆]]

Attachment: Additional fix - v1

This should take care

Comment 12

[Martin Schröder [:mschroeder]]

Comment on attachment 333356 [details] [diff] [review]
Additional fix - v1

r=mschroeder

Comment 13

[Philipp Kewisch [:Fallen][☁️📆]]

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED

Comment 14

[Andreas Treumann]

Checked in lightning 2008081218 and sunbird 20080812 -> VERIFIED