Hia, diving back into quiz now :)

Found a few bugs in the results browser:

  1. when anonymous users have taken a quiz: the username column is blank.
  2. the browser prints the plain username where it should use theme_username

see screenshot for both!

CommentFileSizeAuthor
quiz-results-names.png49.84 KBvegardjo

Comments

zeezhao’s picture

This is also related to my request here: http://drupal.org/node/927478

If theme('username', ...) is used, then http://drupal.org/project/realname works automatically to show full name.

vegardjo’s picture

I'm experimenting a bit with this, to fix theme_username you can change line 1811 in quiz.admin.inc from

$options[$id] = check_plain($res_o->name);

to

$options[$id] = theme('username', $res_o);.

This solves the following:

  • theme_username is respected
  • user_access('access user profiles') is respected
  • The name for anonymous users is printed

One remaining issue is that the browser filter for username still filters for the value in $user->name ($res_o->name) instead of the values in theme_username, haven't quite figured that one out yet..

zeezhao’s picture

Thanks. This solves my issue in #1.

sivaji_ganesh_jojodae’s picture

Replacing

$options[$id] = check_plain($res_o->name);

to

$options[$id] = theme('username', $res_o);. 

The above fix may not work when someone want to override theme_username because $res_o is not a $user object though it is an object type with name and uid attributes defined. Themer might expect some other attributes present in $user object.

I propose to use straightforward fix.

$options[$id] = empty($res_o->name) ? variable_get('anonymous', t('Anonymous')) : check_plain($res_o->name);
zeezhao’s picture

I still prefer the solution:

$options[$id] = theme('username', $res_o);

with the use of http://drupal.org/project/realname

- it enables overriding theme('username', ...)
- it takes care of anonymous user setting
- it enables real names or other names using defined fields to map this
- you can define which forms or screens you want it to bypass
- it works with other drupal modules consistently, if they use theme('username', ...). Your proposed fix will break this rule...

I am using it in production with the above change, and no issues so far.

edit:
Suggestion - add the missing attributes others may expect into $res_o to make it consistent? Then you can use @vegardjo's solution. Its easier to use the realname module to control how people want to see names.

vegardjo’s picture

Hia Sivaji, that's a good point, but as Drupal modules should use theme_username when printing a user name your solution isn't optional as it only solves one of several issues with this (as pointed out in #2 and #5. We could change the line to:

$options[$id] = theme('username', user_load($res_o->uid));

..this way we get our desired output, and theme_username gets the full user object. It's probably a bit slower, but I believe we need to sacrifice that.

The larger issue here however is the search / filter, and I personally do not have the coding skills to solve this. I guess the filter does a AHAH search in the db for the values of res_o->name, but what it has to do is search the values of whatever the $output of theme_username is, which naturally can and will stored in different places from site to site. I don't know how such a thing best could be solved?

..one alternative (from the very top of my mind) could be looking into offloading this from the server and do a javascript search for the values instead, but I don't know how that would work with pagination etc..

falcon’s picture

The reason we don't use theme username is the search and filter issue. I don't know of any good ways to solve it except caching the output of theme username in a db table, and I don't think it is worth the hazzle. It will be better if we can make ppl decide the columns in the result table for future versions of quiz. That way sites using real names can put last name and firstname or a combo into one column. Others can put term names into another column...

falcon’s picture

Status: Active » Fixed

Sivajis fix has been commited:

$options[$id] = empty($res_o->name) ? variable_get('anonymous', t('Anonymous')) : check_plain($res_o->name);

We'll have to add views support or something in future versions of quiz to handle the real name issue I think... :/

vegardjo’s picture

Title: Results: name for anonymous user not shown + theme('username') » theme('username') in result browser.
Version: 6.x-4.0-rc9 » 6.x-5.x-dev
Category: bug » task
Status: Fixed » Active

I see the problem, and it doesn't seem to be any elegant solution for it. Adding Views support would be great for many reasons, but I'm afraid that wouldn't be an optimal solution for this problem either. You would need to use exposed filters to search each field that theme_username consist of (in our case one "firstname" field and one "lastname" field), and the filters would then come on top of the table and not integrated in the table headers like now..

If you don't mind I'm moving this to 5.x and setting it active again, just so we don't forget it?

We have an instructor now who needs theme_username in this browser as a) he wants to access the user profiles from the result list, and b) doesn't recognize many of the names from the result browser in different user listings in his course, and it's very hard for us to explain why this is so.. We will probably patch this internally so we get the username but lose the search.

falcon’s picture

Yeah, and also requiring views is something we would like to avoid, but it would also add the ability to filter and sort on all kinds of data(cck fields, terms etc.) which would be awesome in this context.

Another option is to enable other modules to hook into the question browser and result browser, allowing them to add and remove columns from the tables. That way you would be able to add firstname + lastname in one column.

If you provide a patch for this I would be happy to commit it. (I would also be happy to write it, but it will take some time before I get the chanse to do that...)

vegardjo’s picture

Cool, we'll put it on our list here, and have a look today at when we can prioritize it!

Just to clarify: the patch would be a patch to allow other modules to hook into the result browser at first, to add / remove / manipulate columns? It sounds like a very good idea to me, and one that could solve this particular issue better than a Views integration would (which would be fantastic too, but mainly for other reasons).

Any quick pointers on approach here? I guess the hooks would be added in quiz.admin.inc, and that the quiz-results-browser.tpl.php would need a rewrite? And are we talking about 4.x or 5.x? I'm thinking hooks can be added to 4.x but if we need to rewrite the template file that would maybe be breaking API and it would therefore need to be done in 5.x?

falcon’s picture

Yes, the patch would be a patch to allow other modules to hook into the result browser at first, to add / remove / manipulate columns.

It will go into Drupal 7 so for the data-part we will be able to utilize the new DB abstraction layer to rewrite the queries. In addition the entire "theme" for the form will need to be rewritten. This most likely includes changing the js.

djdevin’s picture

Version: 6.x-5.x-dev » 7.x-5.x-dev
Component: Code - Quiz module » Code - Views
Issue summary: View changes
Status: Active » Closed (fixed)

Fixed in 7.x-5.x with the Entity/Views conversion.