Open Bug 153244 Opened 22 years ago Updated 3 years ago

Need UI hint in record pane for LDAP directories

Categories

(SeaMonkey :: MailNews: Address Book & Contacts, defect)

defect
Not set
normal

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: kmurray1115, Unassigned)

References

Details

(Whiteboard: [adt3][ue3])

Not sure if this is the way we did it in 4.x, but if you are in the Address Book
and select an LDAP directory in the directory/AB pane, the records pane should
display something to give the user the hint that they need to (in the case of an
LDAP directory) type in some search terms in the quick search field. The reason
this becomes important is due to the fact that we auto load local address books
when they are selected in the directory pane, but it's obviously not prudent to
do so for large directories.

We may want to include some text in the record pane such as:
"Type a search term to display records in this directory"

(This is obviously not the correct wording.)

The wording does not need to apply to local address books either, as we will
always go ahead and load the local records and not need to display the text hint.
I agree this is a good idea. 4.x didn't display anything (just blank).

Robin, can you suggest appropriate wording?

"Enter a name or email address in the text field above."
This is a great suggestion. Suggested text: "To search for matching entries,
type a name or email address in the field above."
Much better. :-)
Blocks: 156960
Keywords: nsbeta1
Whiteboard: [ue3]
QA Contact: nbaca → gchan
Mail triage team: nsbeta1+/adt3
Keywords: nsbeta1nsbeta1+
Whiteboard: [ue3] → [adt3][ue3]
Reassigning.
Assignee: racham → shliang
Target Milestone: --- → mozilla1.4beta
Product: Browser → Seamonkey
Assignee: shliang → mail
QA Contact: grylchan → addressbook
Target Milestone: mozilla1.4beta → ---
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This still happen in Thunderbird 3 RC2 (Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.1.5) Gecko/20091130 Thunderbird/3.0) and in Thunderbird 2.0.0.23 (20090812).

SeaMonkey 2.0 Contacts Manager is based in Thunderbird 2 or 3, no?, very probably the problem persists (I cannot tested now in SeaMonkey).

It's possible re-assign the product to 'MailNews Core'?

What is needed to change the state to CONFIRMED?

--

Bug 523364 related or dupe.

--

I propose another solution, like in the addon 'Contacts Sidebar' (currently only for TB2, http://jpeters.no-ip.com/extensions/?page=tb_cs, only works with the sidebar, not with the address book window -but should do the same-), do ever a default search looking for all the contacts until the limit set by the configuration property 'ldap_2.servers.My_LDAP_Server.maxHits' (to avoid performance problems with large directories, and the user can decide the limit in the Directory Properties Window -the UI for this already exists!-), and taking care with the problem of duplicates described in Bug 462792 (it exists a temporary unconfirmed fix, see Comment#11 by Hunter Perrin, that clear the previously results before do a new search).
You need to log in before you can comment on or make changes to this bug.