6.0.0-git
2019-04-21

[#855] default first listing in the Browse
Summary default first listing in the Browse
Queue Turba
Queue Version HEAD
Type Enhancement
State Resolved
Priority 1. Low
Owners
Requester m.zdila (at) episoftware (dot) com
Created 2004-11-19 (5266 days ago)
Due
Updated 2007-06-14 (4329 days ago)
Assigned 2004-11-20 (5265 days ago)
Resolved 2007-06-14 (4329 days ago)
Milestone
Patch No

History
2007-06-14 18:44:53 Chuck Hagenbuch Comment #8
State ⇒ Resolved
Reply to this comment
While better backend searching is definitely still a goal, the main 
issues of this ticket have been resolved - we default to 'A' if there 
are too many objects on the page.
2005-12-27 18:03:07 Jan Schneider Comment #7 Reply to this comment
What was the reason for the (composite) name field initially?
I don't really remember, but my opinion now is that while seperating
the name field makes some things easier, it also implies that the
application knows what a name looks like in a way that's not always
going to be right - makes putting in an entry for a company more
awkward, for instance.
Why? We could still use the user preference to display (aggregated) 
name fields, or only show them as separate columns. Company names are 
no problem either, because any sane user would put them completely 
into the last name field anyway if he has separate fields.
If it's doable and not too confusing, I'd like to see us go to a
model where you can only sort by last name if last name is a seperate
field.
The same is true for first name sorting then, because we don't know 
which format the name fields have. We could only sort for name then, 
whatever that means.
That way it can be fast for everyone and there's the option to
have the composite name field for those who want it, without the
baggage of trying to treat it as anything other than a string.
That would be the cleanest solution, but I bet that people who rely on 
the name format preference won't like it.
2005-12-27 16:37:10 Chuck Hagenbuch Comment #6 Reply to this comment
What was the reason for the (composite) name field initially?
I don't really remember, but my opinion now is that while seperating 
the name field makes some things easier, it also implies that the 
application knows what a name looks like in a way that's not always 
going to be right - makes putting in an entry for a company more 
awkward, for instance.



Of course, if the program isn't going to make assumptions, then we 
really shouldn't have the "sort by last name" feature either.



If it's doable and not too confusing, I'd like to see us go to a model 
where you can only sort by last name if last name is a seperate field. 
That way it can be fast for everyone and there's the option to have 
the composite name field for those who want it, without the baggage of 
trying to treat it as anything other than a string.
2005-12-27 16:22:25 Jan Schneider Comment #5 Reply to this comment
I don't have a bright idea either, but maybe this is another good 
reason to use separate first/last names by default. What was the 
reason for the (composite) name field initially? The LDAP cn attribute?

Maybe we should default to using separate fields, and still offer the 
formatting capabilities for full name fields where necessary. The 
paging could be supported server side for separate fields then.
2005-12-07 22:28:10 Michael Rubinsky Comment #4 Reply to this comment
We don't currently have a preference for which page to start with
(instead of all), and we do filtering client-side. We should fix both
of those, but patches would help immensely.
Currently, the paging works based on the first character of the 
displayed 'name' field - which is dependent on the user's name format 
prefs.  How would we go about filtering server-side without making 
assumptions about the field structure on the backend?  In other words, 
we can check the prefs and see we are displaying "Lastname, Firstname" 
but how can we search for this server side - not knowing if there is a 
'Lastname" field available, and if it is, what is it called?  I 
thought of putting a 'paging_search' entry into $cfgSources, but that 
would force the name format pref to be the same  system wide, not per 
user...  We could put it into the user prefs, but would something like 
this be intuitive to the user?



Thoughts?
2005-09-23 17:31:35 Chuck Hagenbuch Comment #3
Taken from Horde DevelopersHorde Developers
State ⇒ Accepted
Reply to this comment
We don't currently have a preference for which page to start with 
(instead of all), and we do filtering client-side. We should fix both 
of those, but patches would help immensely.
2005-08-07 10:59:39 Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
The browse view should display the default address book meanwhile. Not 
sure about the paging issue, has this been resolved already?
2004-11-20 05:00:25 Chuck Hagenbuch State ⇒ Assigned
Assigned to Horde DevelopersHorde Developers
 
2004-11-19 13:26:03 m (dot) zdila (at) episoftware (dot) com Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 1. Low
Summary ⇒ default first listing in the Browse
Queue ⇒ Turba
Reply to this comment
When I choose Browse from the menu, the default is to display All the 
contacts. I have many contacts in my LDAP address book and it tooks 
too long to list them all.  It would be good to add a setting into the 
preferencies to set default first  listing in the Browse. The same 
problem I encounter while composing an email in the IMP and choosing 
the addressbook.



BUT something more. When I choose to display only names beginning with 
a letter "Y", it tooks as long as I would display all the entries, 
although there are no such names. I see on the LDAP server that sldap 
proccess is running during that time at nearly 100%. It leads me to 
the fact that the filtering is done on the client side (client = 
php@apache, server = LDAP). Is it like that? If yes, please consider 
to query only the contacts beginning with the specific letter. If not, 
then the problem is maybe with the OpenLDAP server I use.

Saved Queries