I think (if I understand it right), I would suggest that: - There be a "big red button" that the proctor can push at the start of the test that goes and munges the role-permission map of the object(s) which comprise the test, maybe granting "View" access to "Authenticated" at that time. Before that, "View" would be restricted to "Manager". Alternately if there is no proctor, do it via a timed event (maybe an XML-RPC call via a cron job). - The "finish taking this test" button when pressed would cause the application to a) "lock" the test results (the user can't edit the answers anymore, even if he backs up in the browser) and b) "unlocks" the answers (by granting the submitting user the "View" local role on the object that comprises the results). This of course implies that the tests, test results, and answers are factored into separate objects. On Fri, 2004-04-30 at 19:38, Dennis Allison wrote:
On Fri, 30 Apr 2004, Chris McDonough wrote:
On Fri, 2004-04-30 at 18:28, Dennis Allison wrote:
I want to add some special checking to prevent direct, through the web access to authenticated users who, I discover, can get a second browser window and move around the site from URL independent of access path. [...] you aren't, it's possible that you may be "fighting the framework" a little bit here and should maybe take a step back and see if there's a way to solve the problem using the builtin Zope security model.
There is one way, but the option of 10000 or more roles boggles the imagination.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )