Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Profile Property searchesProfile Property searches
Previous
 
Next
New Post
1/16/2007 11:05 AM
 

I have an interesting problem... I wrote a custom import to pull data from our HR software into DNN and it works beautifully.  Additionally, I have a "company directory" module plugged in to that data to search for people in different departments, list whole departments, etc. 

So the problem is that if I don't touch the profiles at all (no updates), my company directory can find people and their supervisors and/or direct reports by using the following code (this is to get somebody's supervisor, having alraedy pulled their supervisor ID from their profile):

UserController.GetUsersByProfileProperty(PortalId, "Employee ID", supervisorId, 0, 100, ref tmp)

However... if I go update, say, my own profile... I can no longer find my supervisor using this code, unless I also go touch their profile too.  An interesting side effect I noticed, is that in the User Management of DNN, I *CANNOT* search by those custom profile fields, unless I manually touch each and every individual profile and update it.  The second I update them, I can suddenly perform a search using those custom profile fields. 

I figure it has something to do with not being able to search by the profile field in User Management, though as long as I do a completely fresh import and don't touch anything, then it all works just fine.

This may be a non-issue because it doesn't seem to occur in my dev environment (4.3.7), but does in my staging environment (4.3.6).  I will try upgrading the staging environment and post observations.

- Fooberichu


-- Jon Seeley
DotNetNuke Modules
Custom DotNetNuke and .NET Development
http://www.seeleyware.com
 
New Post
1/16/2007 3:10 PM
 

**Update**

I installed 4.4.0 on my staging environment and the problem still persists.  I cannot search by my custom profile properties within the User Management unless that profile has either been manually updated by myself or somebody else.  With that in mind, only those that are manually updated can seem to find each other using the code above (UserController.GetUsersByProfileProperty(PortalId, "Employee ID", supervisorId, 0, 100, ref tmp)) and only those that haven't been updated at all can find each other using that code.  They seem to be non-existant to each other otherwise.

So... rack your brains and see if anybody can figure that one out.

-- Fooberichu


-- Jon Seeley
DotNetNuke Modules
Custom DotNetNuke and .NET Development
http://www.seeleyware.com
 
New Post
2/13/2007 10:20 AM
 

So nobody seemed to want to help me identify this problem... but I figured it out on my own.  Thought i'd post it just to be nice:

The problem is two-fold; one, a bug in the GetUsersByProfileProperty stored procedure which, when it uses the "LIKE" clause doesn't wildcard it at all, so it ends up being an equals anyway.  The second was the inconsistency of my own data (based on an import).  I had an "Employee ID" field that in some cases had a leading 0;  each record also has a "Supervisor ID" field, which, in some cases, included the leading 0 and in others not.  Because of that inconsistency, a "0686" was not equivalent to "686" and didn't turn up results.  As soon as I identified that and removed the leading 0, my searches all magically worked again.

I have reported the bug in the stored procedure, though I think it'll be hard to justify wildcards and then to decide where wildcards should go (should wildcards be included both before and after the property value, or just one or the other?).  At least I know how to fix my own issue and can leave it up to the core team to decide what is best to do about the stored proc, if anything.


-- Jon Seeley
DotNetNuke Modules
Custom DotNetNuke and .NET Development
http://www.seeleyware.com
 
New Post
2/13/2007 1:10 PM
 

We don't support wildcards in the stored procedure (per se).

The Users.ascx control adds a "%" sign after the search text so you get any user whose property starts with the text provided.

If you wish to implement wildcards before and after you can add the "%" sign before and after the search text in your implementation.


Charles Nurse
Chief Architect
Evoq Content Team Lead,
DNN Corp.

Want to contribute to the Platform project? - See here
MVP (ASP.NET) and
ASPInsiders Member
View my profile on LinkedIn
 
New Post
2/13/2007 1:21 PM
 
Oh, my bad... of course you'd want to do it via the UI and not the DAL.  It didn't even occur to me that that would be the reason why they weren't included in the stored proc.  Sorry about that.

-- Jon Seeley
DotNetNuke Modules
Custom DotNetNuke and .NET Development
http://www.seeleyware.com
 
Previous
 
Next
HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Profile Property searchesProfile Property searches


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out