scan description and location fields for a URL and populate URL field

NEW
Unassigned

Status

Calendar
General
--
enhancement
11 years ago
7 months ago

People

(Reporter: Robert Eden, Unassigned, Mentored)

Tracking

Details

(Whiteboard: [good first bug][lang=js])

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Firefox/1.5.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Firefox/1.5.0.8

often a URL is given in the body or location field in an Outlook meeting notice  and presumably other tools as well.

It would be nice if the URL field would be auto-populated with this value so it could be used by other bugs (like a visit URL context option)

If multiple URLs are found, the "location" field should take precedence.

Multiple URLs can be supported if multiple URL enhancement is worked, if not, just pick one (better than nothing).

Reproducible: Always
Component: Import and Export → General
OS: Windows XP → All
QA Contact: import-export → general
Hardware: PC → All
Sounds like a reasonable request, confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [good first bug]
IMO depends on proper attachment support.
Depends on: 382951
(Reporter)

Comment 3

9 years ago
I disagree on the dependency.  

This bug is for a quick/simple attempt to provide a clickable link in a calendar item.  There's no way it will have the intelligence to know if an item should go in a URL (web page with more information) or ATTACH (documents).

The URL property is still better than what we have now (no links at all).

For what it's worth, I typically see this used for GotoMeeting and WebEx type meetings. The meeting URL is currently in the body.  Would be nice to have it in the right field. (and usable w/o copy/paste)

Robert
(In reply to comment #3)
> This bug is for a quick/simple attempt to provide a clickable link in a
> calendar item.  There's no way it will have the intelligence to know if an item
> should go in a URL (web page with more information) or ATTACH (documents).
> 
> The URL property is still better than what we have now (no links at all).
IMHO the URL property doesn't fit for that, and unless you are sure the URL points to an alternative representation of the item, we shouldn't use it. We could safely use attachments and could achieve easy clicks to those attachments in the event dialog.

<http://tools.ietf.org/rfcmarkup?doc=draft-ietf-calsify-rfc2445bis-08#section-3.8.4.6>
(Reporter)

Comment 5

9 years ago
attach: "This property provides the capability to associate a document object with a calendar component."

So Attach is for for document attachments and not really appropriate for a virtual meeting room either.  I think URL is closer to that purpose.

I think a dependency is a little strong.  Let's get *some* parsing in there for URLs first... depending on how clicking "ATTACH" properties works out, It will probably be fine, but don't think it's worth blocking this bug. 

Heck, maybe this bug can get fancy and determine if Attach is more appropriate via the doc type!




Whiteboard: [good first bug] → [good first bug][mentor=Fallen][lang=js]
Anyone wanting to step up,  this can be done with the ATTACH propery as Robert says. In our codebase, just add an attachment with the found URL. See also the mozITXTToHTML converter.
No longer depends on: 382951

Comment 7

4 years ago
I will take this bug.
Assignee: nobody → admin
Status: NEW → ASSIGNED

Comment 8

4 years ago
Can you confirm that you're still working on this bug?
Flags: needinfo?(admin)

Comment 9

3 years ago
OK, no activity in a while, returning to the pool.
Assignee: admin → nobody
Flags: needinfo?(admin)
Status: ASSIGNED → NEW
(Assignee)

Updated

3 years ago
Mentor: philipp@bugzilla.kewis.ch
Whiteboard: [good first bug][mentor=Fallen][lang=js] → [good first bug][lang=js]

Comment 10

2 years ago
Martin and Mike, I could help with this one here. Please also note I have not worked on any other Firefox bugs. So I might need your help.
Looking forward to your help! First of all I'd suggest to get yourself aquainted with the build system and code base. You can see how to build Thunderbird+Lightning here: https://developer.mozilla.org/En/Simple_Thunderbird_build

once you have done that, you will be able to produce patches that apply to the development version. If you prefer, you can probably also use nightly builds and just work on the unzipped code to get started.

When you have this set up, you can use mxr.mozilla.org/comm-central to browse the source code. You probably want to check out the item conversion code at http://mxr.mozilla.org/comm-central/source/calendar/base/content/calendar-dnd-listener.js#11

Parsing the body could get a little tricky, I'll have to dig into how to do that. I recall there was something about using the module http://mxr.mozilla.org/comm-central/source/mailnews/db/gloda/modules/mimemsg.js to re-parse the mime message for the body parts. Then you could either directly use the html parts to find a link, or if there is only a text part then use above mentioned converter to figure out if there is a link in it, or just use a regex.

If you'd like ad-hoc answers, feel free to visit me on IRC. My nickname is Fallen, on irc.mozilla.org #calendar.
You need to log in before you can comment on or make changes to this bug.