Closed (fixed)
Project:
Quiz
Version:
7.x-5.x-dev
Component:
Code - Views
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
4 Oct 2010 at 14:09 UTC
Updated:
6 Jun 2014 at 04:19 UTC
Jump to comment: Most recent
Hia, diving back into quiz now :)
Found a few bugs in the results browser:
see screenshot for both!
| Comment | File | Size | Author |
|---|---|---|---|
| quiz-results-names.png | 49.84 KB | vegardjo |
Comments
Comment #1
zeezhao commentedThis 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.
Comment #2
vegardjo commentedI'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:
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..
Comment #3
zeezhao commentedThanks. This solves my issue in #1.
Comment #4
sivaji_ganesh_jojodae commentedReplacing
to
The above fix may not work when someone want to override
theme_usernamebecause $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.
Comment #5
zeezhao commentedI still prefer the solution:
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.
Comment #6
vegardjo commentedHia 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..
Comment #7
falcon commentedThe 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...
Comment #8
falcon commentedSivajis fix has been commited:
We'll have to add views support or something in future versions of quiz to handle the real name issue I think... :/
Comment #9
vegardjo commentedI 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.
Comment #10
falcon commentedYeah, 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...)
Comment #11
vegardjo commentedCool, 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?
Comment #12
falcon commentedYes, 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.
Comment #13
djdevinFixed in 7.x-5.x with the Entity/Views conversion.