Now you can easily query all or some user profiles to show in user directories or show extracts of users for any kind of use case. Highly cachable :)
Common Use Cases
- user profile pages
- web-based member directories
- hidden report-pages to show users according to certain criteria
- Title field - this is the field from the profile, which should be the title. This is important because each content-item must have a title. By default it's the DisplayName.
- Properties - these are the properties we want to use in our query. Other properties are not passed on
- Content-Type-Name - this is not really important, but there are cases where you want to name your content-type.
- UserIDs - you could filter by user-id to only retrieve one or more users, like "52560,3050". This is mostly useful when you want to provide a list with all users, and sometimes run a query to get more details on a use based on a url-param.
Performance and Caching
The DNN User Profile API is very, very slow. For each user retrieved it will hit the database, so retrieving the profile of 3'000 users took about 4-5 seconds in our scenario. This is not acceptable, so we recommend that you add a cache data-source to your query as needed.
The security impact is very low, as you choose which fields are delivered in the profile. In addition, no password-field is provided, even if you do try to access it. But as a developer you must remember that there may be confidential information or something, just keep your brains on as you work with people-data.
Fields on a User Profile
This is just for the techies: DNN has grown a bit over time, so it has different places where data is stored. The following fields are technically from the user-object, and stored in own tables in DNN:
All other properties come from the configurable properties on each portal, so these are a bit like the EAV data model in 2sxc.