Library Module
About 7 months ago, I was asked to develop a library system for one of the programs at WashU. I considered a number of different options.
The first option was just to write a completely customized system. In retrospect, that probably would have been one of the quickest options since I had previously created a library system for A&SC's library and could start with that code and tweak it. However, I was concerned about creating yet another custom application. The second option was to find an opensource application that would fulfill the program's requirements. However, the program did not barcode their library items, and every application I found assumed that the library did. (As a note, I think the program SHOULD use barcodes or some other unique identifier. Otherwise, how can you keep track of individual copies of the same book?) The third option was to use Drupal, and that's what I decided to do.
Previously, I had done some pretty creative stuff with Drupal without ever needing to write a custom module: a work order/inventory system, a digital audio library, etc. But this library was going to require one. I estimated that it would take a couple of months of solid work since I was going to need to learn how the guts of Drupal worked.
Man did I underestimate.
Now - in all fairness - I did get pulled onto a handful of other projects, and I've seriously enhanced the original module I had envisioned. I decided that it would be great to contribute the module back to the Drupal community. I wrote a module proposal and was given a Drupal CVS account. Flexibility was my objective. Folks could define their own content types for library items by adding a custom content type to the library. Items could be for reference only. I built in the capacity for users to create custom 'library actions'. I added optional due date functionality (not something my client needed, but I was feeling creative.) I created a tab showing the history of each library item. I even started working on a cron to send automatic emails to users with overdue items.
Then, I realized that I hadn't built the module to handle multiple copies of an individual book. Granted, the client I was building it for wouldn't use that functionality, but for the module to appeal to a wider audience, it needed to be there.
So I ripped my hard work to complete shreds and started again.
I needed to dissociate a library item from the node object. Nodes could thus have multiple library items associated with them. For example, you have 3 copies of 'Tom Sawyer'. The node is named Tom Sawyer. The node has whatever fields the user has defined for that content type (e.g. Publisher, Author, etc). Then, there are 3 instances of that item, each of which can be checked in and out independently.
After a few more weeks of hard work, I was really proud of the result. Then I realized another limitation I had imposed.
I had created a sub-module called 'patron'. This module defined a custom content type for patrons of the library. The reason I chose not to have patrons as users was because the WashU program who would be using my application would be having students entering/editing the library patrons, and I did not want to give them the ability to delete the Drupal superuser account or even one of the patron accounts. (On a tangent - I think it is ridiculous that editing and deleting users is combined into a single permission. ) In Drupal 6, editing and deleting nodes are separate permissions, so it was more convenient to make patrons content. However, like the e-commerce module, a library might want to allow a patron to log in and view their own information, renew books, place books on hold, etc. I wasn't planning on building in that functionality, at least not initially, but if I didn't make the original module flexible enough, it would be really difficult to add later.
So I'm still ripping apart and rebuilding the module. I still haven't submitted my initial version to CVS because I'm not comfortable working with source contron....
My to-do list currently includes making the item status text customizable, displaying patron information in user profiles or on a tab off the user profile, separating checkout periods by content type, automatically updating the related patron if a user's email changes, and integrating the views module.... among other things. *sigh