Closed Bug 316916 Opened 19 years ago Closed 12 years ago

Implement Task filter (Search for tasks in task list on tasks tab) / Implement "Find Events or Tasks"

Categories

(Calendar :: Tasks, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kainhart, Assigned: mmecca)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 4 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Tasks are not searchable alongside events. Since tasks are basically events without dates attached to them, they should be searchable as events also are. It is also likely that some will like to dissable this feature so an optional setting either on the main screen or in an advanced search screen would probably suffice.

Reproducible: Always

Steps to Reproduce:
1. Open Sunbird and select a valid calendar containing tasks.
2. Make sure the Search Bar is visible by checking it in the View menu.
3. Search for word that appears in one of the tasks on the calander.

Actual Results:  
No results are shown for tasks that match the text in the "contains" text box.

Expected Results:  
Tasks should be shown along with Events in the search results unless specifically blocked with some sort of option.
Sorry the identifier should be:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051104 Mozilla Sunbird/0.3a1
The search in the unifinder is only for the selected category of events. So this is an enhancement request.
Assignee: mostafah → nobody
Severity: normal → enhancement
Component: General → Sunbird and Calendar-Extension Front End
OS: Windows XP → All
QA Contact: general → sunbird
Hardware: PC → All
Summary: Can not search for Tasks → Search for Tasks
(In reply to comment #2)
> The search in the unifinder is only for the selected category of events. So
> this is an enhancement request.
> 
Note that we can probably get this in pretty easily with the new list-view I'm working on.  It'll be a combo unifinder+task-list, with the quick-search option just like the current unifinder.
Component: Sunbird Only → Tasks
QA Contact: sunbird → tasks
Tasks are not searchable. With hundreds outstanding tasks search function is quite essential.
I'd like to see a quick search on tasks by Title, that would be similar to Thunderbird's quick search on Subject or Sender. It can replace the "Click Here to Add a New Task" block.
(In reply to comment #5)
> I'd like to see a quick search on tasks by Title, that would be similar to
> Thunderbird's quick search on Subject or Sender. It can replace the "Click Here
> to Add a New Task" block.
> 

I would see it more like joey said (comment #3) as the same way to search event in the event unifinder.

@joey: I would like to know if you are still working on this task unifinder if it's you who did that work, cause I'm trying to implement some sort of task mode with it (yea another bug (bug 405508) but it reach this one) 
Sounds like a valid feature request.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: helpwanted
(In reply to comment #12)
> *** Bug 480857 has been marked as a duplicate of this bug. ***

I was going to request a Task Search specifically for Thunderbird Lightning Tasks.
It looks like this is already in the works, and that MANY Duplicate Bug requests have already been "marked as a duplicate of this bug".

@Philipp:  Is the creation of a Task Search (implemented either from the Edit submenu like the TB email search... or from the View Submenu like the event search in Calendar) going to be implemented?  I could find no reference of it on https://wiki.mozilla.org/Calendar:Roadmap .

@Philipp:  Was the change that Joey Minta was working on in 2006 put on hold?

Thank you.
Philipp, I've made a mockup of how I imagine the task search. Would this be a feasible UI? (requesting feedback)

The task search box is conceptually similar to the new TB filter bar: quick-filter only current view. For the user, focussing or showing the task search bar should work similar as working with the filter bar. Therefore:
Bug 570256 - Implement Ctrl+F keyboard shortcut for Lightning's "Find Events" search bar. Furthermore, Ctrl+F should also focus/show the "search tasks" search bar when we're in task mode.

Phil, I'd like your feedback on the concept of those bugs as well.
Attachment #449387 - Flags: ui-review?(philipp)
Thomas, there is also a bug for the search field of lightning to be combined with the search field of thunderbird. (laer
https://bugzilla.mozilla.org/show_bug.cgi?id=461032

However your mockup seems to be good as long as previous is not solved
Mareen, thanks for pointing out bug 461032! (btw, you can shorten your links by just typing "bug 461032" into your comment, it'll be autolinkified after commit).

Bug 461032 - Integrate unifinder search into Gloda and Thunderbird Search Bar

Bug 461032 is surely a good thing, but it does NOT offer the functionality requested by this bug. And I assume it's *much* easier to do this bug compared to bug 461032 (we already have the same filter box for events!).

- Bug 461032 makes Lightning's events and tasks available for TB's *global search* aka faceted search. Faceted search results open in a new tab which is a very complex thing and the result page leaves a lot to desire in terms of functionality.
- This bug, however, wants a simple contextual inline *filter* for the list of tasks that is already on the screen. In fact this bug does for tasks what bug 545955 has done for folders, by implementing a separate(!) in-place quick filter bar in addition to the global search widget. We should do the same for tasks (this bug).
See Also: → 461032
I just realized that the original intention of this bug might have been different from most of the duplicates and my proposal:
- comment 0 wants to include (dated and undated) tasks into the "Find events" search results of the Calendar Tab. iow, a "Find events or tasks" filter.
- most duplicates and my proposal of attachment 449387 [details] want a simple "Find tasks" filter on the Tasks Tab.

Both ideas are certainly valid requests, and perhaps they can complement each other. However, I'd think that the "Find tasks" filter for the task list would be both easier to implement and more needed.
Summary: Search for Tasks → Implement Task filter (Search for tasks in task list on tasks tab) / Implement "Find Events or Tasks"
I can't believe, that there a just that few people that need a tasks filter. 
This missing feature is the main argument why we are looking for a different solution for task management. 
IMHO, it would bring TB a big step forward for all people that want/need to replace Outlook.
Comment on attachment 449387 [details]
Mockup Screenshot 1 - Search tasks.PNG

I don't do UI review, but I wouldn't mind this. It would be better to integrate calendar events into gloda though, this way we'd have a faster search.
Attachment #449387 - Flags: ui-review?(philipp) → feedback+
Assignee: nobody → matthew.mecca
Status: NEW → ASSIGNED
Blocks: 536909
Attached patch Fix v1 (obsolete) β€” β€” Splinter Review
Adds text filter to Task View
Attachment #575719 - Flags: ui-review?(richard.marti)
Attachment #575719 - Flags: review?(philipp)
Attached patch Fix v2 (obsolete) β€” β€” Splinter Review
Fixes missing ';' in Fix v1
Attachment #575719 - Attachment is obsolete: true
Attachment #575740 - Flags: ui-review?(richard.marti)
Attachment #575740 - Flags: review?(philipp)
Attachment #575719 - Flags: ui-review?(richard.marti)
Attachment #575719 - Flags: review?(philipp)
Comment on attachment 575740 [details] [diff] [review]
Fix v2

This looks good.

On OSX the #task-text-filter-field is 2px higher than the #view-task-edit-field (I'm not a ui expert but I don't mind about this difference because it's not so obvious with the rounded border of the new search box).

I propose to change the css for OSX to:

#task-text-filter-field {
    margin: 4px 5px;
}

With this the #task-addition-box will stay on the same height as before.
Attachment #575740 - Flags: ui-review?(richard.marti) → ui-review+
Comment on attachment 575740 [details] [diff] [review]
Fix v2

Review of attachment 575740 [details] [diff] [review]:
-----------------------------------------------------------------

In general the patch looks fine, I haven't tested it though. I'll give r+ and test when the below comments have been resolved:

::: calendar/base/content/calendar-common-sets.xul
@@ +171,5 @@
>      <key id="calendar-delete-item-key" keycode="VK_DELETE" observes="calendar_delete_event_command"/>
>      <key id="calendar-delete-todo-key" keycode="VK_DELETE" observes="calendar_delete_todo_command"/>
> +
> +    <!-- We use the same key as key_find, so it needs to be disabled when the task mode is active-->
> +    <key id="task-text-filter-select-key" key="&calendar.task.text-filter.accesskey;" modifiers="accel"

Can't we use the same command that Thunderbird uses for this? If you add a command handler to the tab-specific controller, then you should be receiving the event.

::: calendar/locales/en-US/chrome/calendar/calendar.dtd
@@ +178,5 @@
>  <!ENTITY calendar.task.category.button.tooltip  "Categorize tasks">
>  <!ENTITY calendar.task.complete.button.tooltip  "Mark selected tasks completed">
>  <!ENTITY calendar.task.priority.button.tooltip  "Change the priority">
>  
> +<!ENTITY calendar.task.text-filter.textbox.emptytext  "Filter tasks... &lt;Ctrl+F&gt;">

Please use the Unicode character "…" instead. Also, the "Ctrl" seems very PC specific. What does Thunderbird do here?

Also, I believe Thunderbird has moved to Ctrl+Shift+K, should we follow this move?
Attachment #575740 - Flags: review?(philipp) → review-
:mmecca, thank you for working on this, it's great to see this moving! It'll add a *lot* of value to tasks.

(In reply to Philipp Kewisch [:Fallen] from comment #23)
> Review of attachment 575740 [details] [diff] [review]:

+1 to all of the above.

A recent example how commands invoked by same shortcut key can cover multiple uses might be the cmd_delete which alternates between Delete (text selection) and Remove Attachment depending on what has focus (bug 526998 attachment 574793 [details] [diff] [review])

> Also, I believe Thunderbird has moved to Ctrl+Shift+K, should we follow this
> move?

Absolutely! Task Filter is in functional analogy to quick filter, which now has Ctrl+Shift+K, so task filter needs the same! Let's not confuse users by using something else again. Ctrl+Shift+K was introduced in bug 564328, so looking at the patches there might also be a good starting point for hijacking the respective commands.
Otherwise, Jim :squib is knowledgeable about these things and the current approach of doing them (while I only know very little about them).
(In reply to Thomas D. from comment #24)
> 
> > Also, I believe Thunderbird has moved to Ctrl+Shift+K, should we follow this
> > move?
> 
> Absolutely! Task Filter is in functional analogy to quick filter, which now
> has Ctrl+Shift+K, so task filter needs the same! Let's not confuse users by
> using something else again. Ctrl+Shift+K was introduced in bug 564328, so
> looking at the patches there might also be a good starting point for
> hijacking the respective commands.

It does make sense to use Ctrl+Shift+K like the Thunderbird quick filter uses, and we could do this by adding a handler for the cmd_showQuickFilterBar command. However, it doesn't look like Seamonkey uses this, so that shortcut key wouldn't work there. That might not be a big problem since the Seamonkey message search doesn't use any shortcut key either.

Alternatively, we could use the cmd_find command with the Ctrl+F shortcut in both Thunderbird and Seamonkey.

Which approach do you think would be better?
Attached patch Fix v3 (obsolete) β€” β€” Splinter Review
This patch works with both the cmd_showQuickFilterBar (Ctrl+Shift+K) and the cmd_find (Ctrl+F) commands in Thunderbird. Only the cmd_find command currently works in Seamonkey, so that shortcut is used for the placeholder text. If Seamonkey implements the QuickFilterBar commands in the future, we would only need to update the strings.

This patch also uses a similar method as in the Thunderbird QuickFilterBar to make the placeholder text platform dependent. I don't have a mac to test this on - could someone please check to make sure this works right?
Attachment #575740 - Attachment is obsolete: true
Attachment #577462 - Flags: review?(philipp)
Matthew, thank you for pushing this forward, which is much appreciated.

(In reply to Matthew Mecca [:mmecca] from comment #26)
> Created attachment 577462 [details] [diff] [review] [diff] [details] [review]
> Fix v3
> 
> This patch works with both the cmd_showQuickFilterBar (Ctrl+Shift+K) and the
> cmd_find (Ctrl+F) commands in Thunderbird. Only the cmd_find command
> currently works in Seamonkey, ...

VETO: I am strongly against introducing two keyboard shortcuts, Ctrl+Shift+K and Ctrl+F, for the same function (task search) in Thunderbird. We should provide only Ctrl+Shift+K for task list search.

Reasons:
1) Having two keyboard shortcuts for the same function is unheard of, and causes problems for support, mnemonic value, and future changes (when the duplicate keyboard shortcut gets removed - see 2) below -, and users have to be re-trained, which is avoidable).
2) Introducing Ctrl+F for task search is *not* a good idea, because I am sure in the long run, we will want to synchronize with TB's main 3pane where Ctrl+F searches the message text. So in our case (tasks tab), we'll want to search the text of the currently viewed task description with Ctrl+F (do we have a bug for that?). More so after implementation of bug 455396, when task description will be editable inline, removing the current pita that we cannot edit things which are right in front of us.
3) We should keep our shortcuts in sync with TB, so Ctrl+Shift+K is the right choice at this time. If TB decides to change that back to Ctrl+F, we'll have to follow that move, but I don't see that change happening very soon.
4) If Seamonkey needs a different shortcut because they only know Ctrl+F, then so be it, let them have their own. Although given 2), it doesn't make much sense either, in the long run, so I'd recommend giving them Ctrl+Shift+K, too, if that's free.

I understand we sometimes take shortcuts when sorting out UI things in comments, but things as delicate as changing search shortcuts need a proper UI-review, imo.
(In reply to Thomas D. from comment #27)
> VETO: I am strongly against introducing two keyboard shortcuts, Ctrl+Shift+K
> and Ctrl+F, for the same function (task search) in Thunderbird. We should
> provide only Ctrl+Shift+K for task list search.

If we just want to use Ctrl+Shift+K I can see two workable options:

1) We just use a handler for the cmd_showQuickFilterBar command. The shortcut key will work in Thunderbird, but not in Seamonkey. If we do this we shouldn't include the shortcut key in the placeholder text at all.

2) Instead of using Thunderbird's command, we use our own key mapped to the same key combination, similar to what I did in Fix v1, and make sure the conflicting keys are disabled appropriately based on tab focus. This is the only way I can see to have it work in both Thunderbird and Seamonkey.

@Philipp, Richard: What do you think?
I think we should go with Option (1) and talk to the Seamonkey folks how they'd like to solve this. While we do support Seamonkey, our main target is Thunderbird. Since Thunderbird shows a Keyboard shortcut in the bar, I think we should too.
I'm also for option 1. You wrote in comment 25 Seamonkey doesn't use a shortcut so this wouldn't be a big problem.
So if SeaMonkey implements a dummy "cmd_showQuickFilterBar", the lightning shortcut would work?
(In reply to Philip Chee from comment #31)
> So if SeaMonkey implements a dummy "cmd_showQuickFilterBar", the lightning
> shortcut would work?

Yes, Seamonkey needs a dummy command with that name and a keyboard shortcut that executes that command. The command needs to be exposed via the tabmail's command handler.
> +        if (textFilter) {
> +            let base = textFilter.getAttribute("emptytextbase");
> +            let keyLabel = textFilter.getAttribute(Application.platformIsMac ?
> +                                                   "keyLabelMac" : "keyLabelNonMac");
> +
Fallen asked me to comment in this bug.
SeaMonkey doesn't (yet) implement platformIsMac. I've filed Bug 706421 to get
this into Suite. In the meantime you can use:

/Mac/.test(navigator.platform) ? "keyLabelMac" : "keyLabelNonMac";

e.g.
+        if (textFilter) {
+            let base = textFilter.getAttribute("emptytextbase");
+            let attr = /Mac/.test(navigator.platform) ? "keyLabelMac" : "keyLabelNonMac";
+            let keyLabel = textFilter.getAttribute(attr);

Which works in all Gecko platforms back to 1.*. I think navigator.platform will
work in Netscape Communicator 4.7 as well.
> SeaMonkey doesn't (yet) implement platformIsMac. I've filed Bug 706421 to get
> this into Suite. In the meantime you can use:
> 
> /Mac/.test(navigator.platform) ? "keyLabelMac" : "keyLabelNonMac";

Looks like Bug 706421 has landed on trunk, so platformIsMac should be good now.
Attached patch Fix v4 (obsolete) β€” β€” Splinter Review
Uses just Ctrl+Shift+K. Untested on mac, please make sure this looks right.
Attachment #577462 - Attachment is obsolete: true
Attachment #578477 - Flags: ui-review?(richard.marti)
Attachment #578477 - Flags: review?(philipp)
Attachment #577462 - Flags: review?(philipp)
Comment on attachment 578477 [details] [diff] [review]
Fix v4

Looks good also under Mac. r+

Small nit (sorry to not to mention the first time). Please can you add in winstripe/calendar-task-view.css this:

#task-text-filter-field .textbox-search-icons {
    margin-bottom: -1px;
}

This makes the textboxes the same height under XP and Win7, but not under Classic there the textbox is still 2px higher. To solve this also this would be to complex.
Attachment #578477 - Flags: ui-review?(richard.marti) → ui-review+
Comment on attachment 578477 [details] [diff] [review]
Fix v4

Review of attachment 578477 [details] [diff] [review]:
-----------------------------------------------------------------

I've only tested this on mac, where it works fine. Unless Philip objects, I'd say we can do this on comm-central now even without the Seamonkey changes. If you like, you could add the dummy <key> and <command> for seamonkey in this patch and ask Philip for review on those parts. If you use the navigator.platform line for testing the right label then that part should be taken care of too, it doesn't hurt Lightning at all.

r=philipp

::: calendar/base/content/calendar-task-view.js
@@ +311,5 @@
> +    let deck = document.getElementById("calendarDisplayDeck");
> +    let tree = document.getElementById("calendar-task-tree");
> +
> +    if (deck && tree) {
> +        document.removeEventListener("load", taskViewOnLoad, false);

It seems you are adding the load event on the window (which is correct) but removing it from the document. I believe window load events do not have to be removed, the reason we had this in some other files is that we were getting multiple load events, because we wrongly added the listener to the document.
Attachment #578477 - Flags: review?(philipp) → review+
> I've only tested this on mac, where it works fine. Unless Philip objects, I'd say we can
> do this on comm-central now even without the Seamonkey changes. If you like, you could
Not going to hold up this bug as I plan to address any fallout myself.
(In reply to Philipp Kewisch [:Fallen] from comment #37)
> ... If you like, you could add the dummy <key> and <command> for
> seamonkey in this patch and ask Philip for review on those parts. If you use
> the navigator.platform line for testing the right label then that part

The Application.platformIsMac part should be fine now that Bug 706421 is fixed. I don't have a Seamonkey build setup on my machine at the moment, so I'll leave the rest to Philip.
Attached patch Fix v5 β€” β€” Splinter Review
Attachment #578477 - Attachment is obsolete: true
Attachment #585624 - Flags: ui-review+
Attachment #585624 - Flags: review+
Pushed to comm-central - http://hg.mozilla.org/comm-central/rev/3ad982e0fa84
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: