Skip to:

Opened 9 years ago

Last modified 5 months ago

#6211 new defect (bug)

"Only Me" profile fields are searchable by other users

Reported by: srucwebmaster's profile srucwebmaster Owned by:
Milestone: Awaiting Contributions Priority: normal
Severity: normal Version: 1.6
Component: Extended Profile Keywords:
Cc: brajesh@…


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)

6211.diff (8.1 KB) - added by boonebgorges 9 years ago.

Download all attachments as: .zip

Change History (11)

#1 @DJPaul
9 years ago

  • Component changed from API to Component - XProfile
  • Version changed from 2.2 to 1.6

@srucwebmaster Thanks for surfacing this from the forums and creating a ticket.

#2 @boonebgorges
9 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 the foreach 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.

9 years ago

This ticket was mentioned in Slack in #buddypress by boone. View the logs.

9 years ago

#4 @boonebgorges
9 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 @boonebgorges
9 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.

#6 @sbrajesh
9 years ago

  • Cc brajesh@… added

This ticket was mentioned in Slack in #buddypress by boone. View the logs.

9 years ago

#8 @DJPaul
9 years ago

  • Milestone changed from 2.4 to 2.5

#9 @DJPaul
8 years ago

  • Milestone changed from 2.5 to Future Release

#10 @boonebgorges
8 years ago

Depends on #6413.

Note: See TracTickets for help on using tickets.