Apache OpenOffice (AOO) Bugzilla – Issue 23631
filtering member lists uses invisible data
Last modified: 2004-08-19 12:25:16 UTC
filtering member lists of projects (e.g. http://qa.openoffice.org/servlets/ProjectMemberList) seems to use (internally) data which in no way is visible to the web site user. E.g., filter the member list of the QA project (link above) for "fs". This gives you exactly one entry: User Real name Roles Assigned issues hde hde Developer View issues There is no "fs" in this list at all. To the site user, this looks as if the search function is unreliable - I wouldn't believe it when I already had an impression that it lied to me ... (well, hde in real life is "Helge Delfs". Is it possivle that internally, the real names for the users still exist - though they vanished from OOo with the site upgrade -, and are still used for the search?)
FS: Thanks for the information. I've filed an internal task for our Community Managers to review the information. I'll update this issue when my internal one has been updated. (adding Louis to the cc list)
confirming. Frank, I've raised the issue's prominence. The default search on OOo should use login names. Louis
oh, well, the default search should use real names, and OOo should display real names. sorry, couldn't resist :)
This isssue is currently being researched and implemented by all parites involved. We are currently working on implementing a solution for this, but at this time I have no updates. I will update this issue in the near future.
Fs Currently the Issue seems to be resolved. Steps 1. Open link http://qa.openoffice.org/servlets/ProjectMemberList 2. In 'Filter the List' option Enter 'fs' & click 'Filter' Result User Real Name Roles Assigned issues fs fs Developer View issues fst fst Developer View issues hde hde Developer View issues The hde is also appear because the search also includes email id search & in the email id the 'fs ' letter seqeunce is present. the email id search just uses characters set ie if u give keywords "ert" it would search the character set "ert" in all email id & will display user names of all user with email id which has the charset 'ert' Closing issue as Resolved Fixed -Mohan
sorry, but this is weird. The subject of this issue is filtering member lists uses invisible data . I don't see how this has changed. I understand that the mail address which "hde" is registered with contains an "fs" (since his real world address is "helge dot delfs at sun dot com"), but that's not the point. The point is: I do a search in a database, and get results which seem not to be related to the search term, since the displayed result does not *contain* the search term. I heavily doubt that anybody expects the real-world email addresses to be searched - those addresses have no relevance in OOo, and of most users, you do not even know it - since they usually only appear as <login>@openoffice.org -, so it doesn't make sense to look for them. Even more: The behaviour you described implies that I can search for all Sun employess by just looking up "sun.com" in the member lists. You could even call this is privacy issue - no real names are allowed, but searching for the email addresses is? So, including the real world email address in the search is weird.
Hi Fs, I completely agree with your views. I forward your opinions to the engineering Department & will post further updates as & when they come Cheers -Mohan
Awaiting for the engineers response.
Hi FS, The last update I see here is that this is supposed to be fixed by implementing the DRPL checking by SOW, but it is on hold right now. Here is the update: the "DRPL checking" SOW is on hold due to Sun budget restraints. So, this probably won't be in place for a few more months at least. Drew Thomas is tracking this closely with Chris Chelene from Sun. Let me know how to best proceed from here. Eric
Whatever "DRPL checking by SOW" is meant to be .... Well, I can't tell collab.net how to handle issues with their products, can I? I described the issue, I described what I think is the severity of the issue, and it's up to collab.net to decide what to do with it, influenced by whatever constraints there are. This may be "won't fix because" over "fixing now" to "fixint later" ...
I am checking with Drew to find out where stand here. Eric
This issue will be superceded by the DRPL (denied restricted parties list, please refer to OOo internal mgmt for more information on this) implementation for which we are awaiting Sun's timeframe to proceed. That work will make this issue invalid.
Quite unorthodox to resolve an issue as INVALID because *somewhere in the future*, it won't be an issue anymore. If I'd do this with a "normal" OOo issue, i'd be told "Don't alienate the community!" - and rightfully so. <sarcasm>Sometimes I wish I could get rid of my own issues equally easily.</sarcasm> <sigh/> Closing issue.