In HEAD, when trying to open a pages view for a profile field (i.e. the page with all the users that have the same value in the profile field, just to be clear on that), I get the following SQL error:
PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'u.access' in 'where clause': SELECT COUNT(*) AS expression FROM {users} users INNER JOIN {profile_value} v ON u.uid = v.uid WHERE (v.fid = :db_condition_placeholder_7) AND (u.access <> :db_condition_placeholder_8) AND (u.status <> :db_condition_placeholder_9) AND (v.value = :db_condition_placeholder_10) ; Array ( [:db_condition_placeholder_7] => 4 [:db_condition_placeholder_8] => 0 [:db_condition_placeholder_9] => 0 [:db_condition_placeholder_10] => 1 ) in PagerDefault->execute() (line 71 of C:\inetpub\wwwroot\drupal-7.x-dev\includes\pager.inc).
I wrote a tiny patch that fixes the problem.
Comment | File | Size | Author |
---|---|---|---|
#10 | 525058-profile-browse-d7.patch | 2.04 KB | andypost |
#8 | 525058-profile-browse-d7.patch | 2.55 KB | andypost |
#7 | Screen shot of error message | 41.86 KB | jerdiggity |
#6 | profile_browse.patch | 2.12 KB | mfb |
pagesview.patch | 596 bytes | oneoftwo | |
Comments
Comment #1
ZoeN CreditAttribution: ZoeN commentedThis tiny patch works like a charm. Check this out, though: http://drupal.org/node/394720 If the profile.module data get migrated to Field API, will that impact this bug?
Comment #2
ZoeN CreditAttribution: ZoeN commentedLooks like this has become a non-issue.
In this thread, there's a proposal afoot to move the "list of users who have X value for Y profile field" functionality out of profile.module into views. It looks very much as if that is happening - in current d7 HEAD, profile fields displayed on user profiles are already no longer linky.
Comment #4
sun.core CreditAttribution: sun.core commentedComment #6
mfbadded basic test coverage - just enough to catch this.
Comment #7
jerdiggity CreditAttribution: jerdiggity commentedJust encountered the same problem:
**************************
**************************
I then applied the above patch and the problem was resolved. Plz also see attached screen shot.
Comment #8
andypostConfirm this bug and this fix.
Same patch also changes "explanation" field to use randomString() because randomName() now should be used to generate machine-readable values.
Comment #10
andypostBack to original, randomString() still broken to be checked with assertText()
So leave this patch as #6 just re-rolled against current HEAD
Comment #11
webchickThanks. Nice to have test coverage for this, too.
Committed to HEAD.