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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ZoeN’s picture

This 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?

ZoeN’s picture

Looks 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.

Status: Needs review » Needs work

The last submitted patch failed testing.

sun.core’s picture

Status: Needs work » Needs review

mfb requested that failed test be re-tested.

mfb’s picture

FileSize
2.12 KB

added basic test coverage - just enough to catch this.

jerdiggity’s picture

Priority: Normal » Critical
Issue tags: +Quick fix
FileSize
41.86 KB

Just encountered the same problem:
**************************

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_0) AND (u.access <> :db_condition_placeholder_1) AND (u.status <> :db_condition_placeholder_2) AND (v.value = :db_condition_placeholder_3) ; Array
(
[:db_condition_placeholder_0] => 1
[:db_condition_placeholder_1] => 0
[:db_condition_placeholder_2] => 0
[:db_condition_placeholder_3] => Male
)

in PagerDefault->execute() (line 86 of /includes/pager.inc).

**************************
I then applied the above patch and the problem was resolved. Plz also see attached screen shot.

andypost’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
2.55 KB

Confirm 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.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 525058-profile-browse-d7.patch, failed testing.

andypost’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
2.04 KB

Back to original, randomString() still broken to be checked with assertText()

So leave this patch as #6 just re-rolled against current HEAD

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Thanks. Nice to have test coverage for this, too.

Committed to HEAD.

Status: Fixed » Closed (fixed)
Issue tags: -Quick fix

Automatically closed -- issue fixed for 2 weeks with no activity.