This is mostly for the question bank use case, but implementing it should ensure better code quality overall through separation of concerns.
In a question bank, some users may be able to view the answers to a quiz question (e.g. teachers) while some shouldn't (e.g. students). Accordingly, #512674: Permission to view answers/solution outside of a quiz was implemented using roles. But there are also items that some teachers should have access to while others don't. E.g. teachers within a school get to see each others' answers but no one else (since they may not really be teachers). This requires a setting on the item itself.
There are modules like coherent_access that allow all sorts of policies on who can see and edit nodes. Unfortunately, the "view solutions" (really "answers") permission is finer grained than the node. We should allow other modules to create access policies in the same way though.
The easiest way to do this is have the answers be in a standard element of the content array and let other modules use hook_view() or hook_nodeapi() to hide answers when appropriate. This way our current role-based answer filter could be replaced or augmented by a more sophisticated filter, depending on the site configuration.
Comments
Comment #1
turadg commentedI first implemented a nodeapi view hook to do this. I had to eliminate drupal_get_form() in quiz_question_view(), which is a good thing in itself. I also changed Multichoice::getNodeView(), with more mixed results. Falcon, I hope it's progress.
But after getting the view content to be alterable by nodeapi, I went on to making it work for questions_export and realized the best way to do it there would be with an access hook. I tried to use hook_access() with a different op, but it seems that's not permitted. So I made a new hook, hook_answers_access($node, $account) and re-implemented the site-wide permission using it. I also renamed the site-wide permission to "view answers for any quiz item".
Once that was all done, my separate module was pitifully small and I realized that such a blanket permission really fits in the main module. But at least now when another module wants to hook into that access, it can.