Archive for July, 2007

Database Connection Security!

I just caught a very important security issue that I had missed! The SQLPAS PlonePAS module requires a database connection to the user/password tables. Since you can’t add a Z MySQL DB Connection (or any dbc for that matter) in the acl_users folder, I left it at the top level root directory. This unfortunately has the effect of making that database connection usable to students in the Members directory, by acquisition! They could conceivably then do a SHOW TABLES, etc to find out student info, including grades!

The solution was to create a Z MySQL DB Connection with the exact same id and create it in the Members folder. That way, if a student creates a Z SQL Method the only connection that he/she sees would be the one to the test database, not the student info db!

Comments off

Workflow Finally Solved!

Well I finally have it working the way I want.

Rundown of flow:

  • Student creates PSFolder
  • Student submits PSFolder
  • PSFolder gets moved to separate folder that only TFs can access
  • TF logs onto account and goes to tf_resources and selects View Submitted Homework
  • TF grades each submitted PSFolder
  • When done, TF returns to student PSFolder
  • PSFolder gets moved back to student folder

New features to be added eventually

  • Incorporate grading pages to enter grades while in workflow (this is complicated)
  • Incorporate archiving of submitted folder in case of disputes later on
  • Email on homework submission/return

Some hard lessons learned

  • If you manage_pasteObjects(manage_cutObjects()) requires both Copy or Move and Delete permissions (need to confirm)
  • manage_cutObjects() takes a list (or tuple?) of ids, not an id. (sort of obvious)
  • portal_catalog gets confused if you do a copy -> paste. do a cut -> paste. Confused means the review_state variable is “private” (the original state) not “submitted”
  • if as a student you can no longer see your home folder, that means some workflow permissions were screwed up, just reset security settings in portal_workflow to clear this up
  • put the object move script in the After section, not Before. otherwise portal_catalog gets confused too, as the state hasnt changed to submitted yet.
  • Properties, based on a db using SQLPASPlugin, need to be set through Plone using setMemberProperties, not directly into the db.
    • I created an external method script to do this. extSetMemberProperty // extSetStudentTFStatus

Parts of the workflow system

  • Portal_catalog: Add index/metadata for TF
  • Portal_workflow: Add PSFolder type
    • Add Variable TF
    • For submit transition use expression: TF = python:here.portal_membership.getAuthenticatedMember().getProperty(‘tf’)
    • Set Script (after) to an external method that handles the move extMoveObjectsPlone
    • For return transition set script (after) to extMoveBackSubmittedPlone
    • Both are in the external file extCopyObjects.py
    • Permissions for the submitted state: Owner should have Access contents, Copy or Move, and Delete
    • You need to edit the Adds to actions box and add a label or else the transition won’t appear (e.g. “Submit to TF”)
  • PSFolders are Plone objects, not ZMI/zclass objects. Create a regular Plone folder to store the moved psfolder objects in the top level portal root, and manually create Plone folders with tf user ids as ids. Make sure this folder is Private!
  • Set permission to private, submitted, graded, etc appropriately.

I’ve added code snippets to the svn server, which can be accessed on trac.reisun.com

Comments off

Workflow Madness in Plone

I’ve been having some difficulty implementing student homework submission. I’ve gotten a crude hack working, but trying to improve it has been more difficult than I imagined. The following excerpt from http://www.zopelabs.com/cookbook/1029298314 will help, I wanted to copy it here so I can refer to it later. (For a while I had forgotten how to access this page!)


I used your idea but ran into a problem because the default action after a change in status is to view the object (at the old location), which results in an object-not-found error.
To fix this, I went into portal_properties/navigation and changed default.content_status_modify.success from "action:view" to "url:../folder_contents" Now when I publish an item, it dumps me into a view of the folder where it came from.It would be nice if it would go to a view of the newly-moved object, but I haven't been able to get necessary redirects working.Fixing Plone's response (was Re: Re: Use one script for many types of objects.) by sh23 - 2004-10-14
I wanted to only be placed in the directory when the object was no
longer there. In /Plone/portal_properties/navigation_properties
instead of modifying default.content_status_modify.success, I created
a new entry:

default.content_status_modify.gone url:../folder_contents

I then modified (a custom copy of)
portal_skins/plone_scripts/form_scripts/content_status_modify by
replacing 'success' with status_string in the return statement, and
then adding the following immediately before the return statement:

if context.restrictedTraverse(context.getPhysicalPath(), default=None) == None:
status_string = 'gone'
else:
status_string = 'success'

This is known to work with CMF 1.4 and Plone 1.1 24 June development version.

Comments off