From WeBWorK_wiki
Revision as of 15:04, 20 February 2008 by Sam (talk | contribs) (New page: DATABASE * Add facility for doing automated database upgrades. This is pretty simple, and should maybe go into 2.2.x, so that we can actually make use of it in the 2.2 -> 2.3 upgrade. ** ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


  • Add facility for doing automated database upgrades. This is pretty simple, and should maybe go into 2.2.x, so that we can actually make use of it in the 2.2 -> 2.3 upgrade.
    • %Y% 2.3.0: Implemented in bin/wwdb_upgrade. -- SH - 23 Aug 2006
  • Finish stripping out legacy GDBM/SQL modules and code. Unify database-related modules -- DB, DBImportExport, CourseManagement backends, etc.
    • %Y% 2.3.0: Legacy code is gone, but unification hasn't taken place yet. -- SH - 23 Aug 2006
  • Improve the DB.pm API. Look into using ready-made CPAN modules to help with this, but only if they don't impose an undue burden. Put more format/value checking and defaults management into DB, so that the various modules that deal with data don't have to worry about this so much. be able to say "my @Problems = $Set->problems" and "$Set->save".
  • Allow sorting/searching/limiting to take place in the database instead of after records are returned, for efficiency.
  • Move some tables that are currently in the course environment into the database. For example, statuses and permission levels.
  • Split set/problem versioning out into separate tables instead of the ",v" method that's currently in use.
  • Add backends for other SQL databases. I'm particularly interested in SQLite, since people seem to have trouble with SQL database server management and SQLite doesn't require a separate server.


  • Expand "Classlist Editor" UI to allow for subscreens for complex operations. Some examples: confirmation of destructive operations, expanded options for importing/exporting classlist files (like assigning CSV columns to DB fields), sanity checks on student data.
  • Rewrite <nop>ProblemSetDetail to encompass editing set and problem data, problem previews, editing who is assigned to a set, and what versions are available (in the case of gateway tests). I envision a tabbed interface to make it easy to switch between editing various aspects of a problem set without "losing your place". (I have extensive notes on this offline.)
  • Integrate previewing into <nop>PGProblemEditor. Factor out the essentials of the "interactive problem processor" from Problem.pm for use here.
  • Rewrite/cleanup Stats, <nop>StudentProgress, Scoring.
  • Arrange for Problem.pm and <nop>GatewayQuiz.pm to have a common superclass where most of the functionality belongs.


  • Clean up the permissions system, so that there really is a single permission for each operation.
  • Audit file/directory, external command, and "eval STRING" handling.
  • Look into making WeBWorK work with taint checking turned on. Write "untaint" routines for various types of data.


  • Move installation/usage documentation into CVS so that it can be easily updated as features change.
  • Convert HTML/Wiki documentation to <nop>DocBook.
  • Clean up POD documentation in PG macros and libraries.
  • Integrate <nop>DocBook and POD documentation.


  • Apache 2/mod_perl 2 compatibility. We need to start porting this and see where the sticking points are. Maybe it will be easy. :)
    • %Y% 2.3.0: Works with non-threaded MPMs. -- SH - 23 Aug 2006
  • Some kind of standards based installer, for example autoconf/automake or Perl Makefile.PL. This should be able to detect paths to external programs, test for Perl modules, and install things into into FHS-compliant directories. (FHS=Filesystem Hierarchy Standard) Having this will make packaging WeBWorK for various operating systems much easier.
  • Packaging for various package management systems. (APT, RPM, <nop>FreeBSD ports)


  • Convert macros to use the parser wherever possible.