Opened 10 years ago
Last modified 12 months ago
#6211 new defect (bug)
"Only Me" profile fields are searchable by other users
Reported by: | srucwebmaster | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Contributions | Priority: | normal |
Severity: | normal | Version: | 1.6 |
Component: | Extended Profile | Keywords: | |
Cc: | brajesh@… |
Description
As noted by user @asitha here, setting profile field visibility to "Only Me" does not prevent that field from being searchable by other users.
This results in profiles with a matching term being returned in search queries by other users, despite the profile field containing the matching term not being visible to those users.
Attachments (1)
Change History (11)
#1
@
10 years ago
- Component changed from API to Component - XProfile
- Version changed from 2.2 to 1.6
#2
@
10 years ago
- Milestone changed from Awaiting Review to 2.3
6211.diff is a prelimary attempt at fixing this. It works (please review the unit tests), but it's quite ugly. Problems:
- User field visibility levels are stored in a serialized array in usermeta. This means it's impossible to solve this problem with a single SQL query. The only way I can make it work on the current schema is to prefetch the user IDs + field IDs that match the search terms, and then to run a separate loop to filter out the items that are not visible to the current user.
- I've chosen to call
bp_get_user_meta()
inside theforeach
loop. This will surely cause performance issues when there are large number of hits and the site has no persistent cache. Alternatively, I could do a single query to fetch it all at once - this will reduce both the number of queries required and the data stored in memory - but it's still going to hit a performance ceiling.
The main change that could be made to improve this whole thing is to move visibility levels from usermeta into xprofile_meta, as "datameta". Then most of this work could be accomplished by a single table join.
It seems to me that moving visibility data to datameta is worthwhile for other reasons - it will simplify other parts of the API as well - but I'd like to hear the thoughts of others before moving forward with it. As we did in the case of 'last_activity' migration, I'd probably want to continue to mirror it in usermeta, in case anyone is referencing it directly that way.
This ticket was mentioned in Slack in #buddypress by boone. View the logs.
10 years ago
#4
@
10 years ago
I've opened #6413 to discuss moving visibility stuff to xprofilemeta. Let's go with the current fix for now, and maybe do the larger switchover in 2.4.
#5
@
10 years ago
- Milestone changed from 2.3 to 2.4
Ugg. I'm reexamining the patch, and it's not going to work as-is. It depends on visibility levels being set for all fields, but I'm not sure that that's always going to be the case. I'm going to move this to 2.4 to handle properly.
@srucwebmaster Thanks for surfacing this from the forums and creating a ticket.