I'm working on a module to build a lending library out of nodes. This is designed around an optimistic lending model where a club or organization has a pool of shared resources and wants to keep tabs on where they are at. It creates a two permission system, people that can be lent to and people that can lend out items (librarians), and keeps a full audit log of lent items, especially which librarian checked things in and out, so tracking down where an item might be is much simpler.
It will also support people putting in requests to lend an item, as with our astronomy club the librarian has to truck a couple of crates to every meeting, and a request function would let them more easily only bring the items people are looking for to the meetings.
The project should be ready in another week or so, some changes up in the git tree now, I wanted to kick off the review process early so that I could make it live and installable through drush when ready.
Comments
Comment #1
berdirPaste a link to your project and set the issue to needs review when you think it's ready for that (reviewing).
Comment #2
sdague commentedHere is the current sandbox link - http://drupal.org/sandbox/sdague/1072704
Comment #3
sdague commentedThis is ready for initial review at - http://drupal.org/sandbox/sdague/1072704
Please review and provide feedback. I'd like to start making alphas available.
Comment #4
sdague commentedbump. I was really hoping someone would look at this and decide if the project can be approved or what I'd need to change. Thanks.
Comment #5
sdague commentedI have confirmed there are no issues as presented by the coder module, and have tagged a 6.x-1.0 release in my sandbox to be ready to go as soon as there is approval on this. Some feedback would be great, as I'd like to get this out and available.
Thanks.
Comment #6
klausi* Never implement hook_init() just for including other files, as this hook gets executed on every page load. This will slow your Drupal site down unnecessarily. Include the files when needed.
* there is an empty comment header on lending_cleanup_records()
* Comments start with a capital letter
* Hooks are annotated with "Implements hook_bla()", "Implementation of hook_bla()" is deprecated.
Comment #7
sdague commentedThanks for the review, I've fixed the issues above in changeset 75d7684 on my sandbox, please take a look when you can.
Comment #8
agentrickardCode looks good.
Notes / Nitpicks
-- lending.info should not declare it's own package for one module.
-- Not sure what DESIGN.txt is. Looks like developer docs.
-- Would be better to take the functions out of the tpl and move to preprocess functions. Slightly more secure if people create derivative tpl files. Ideal is to only have string variables in the tpl.
--
<?php // -*- drupal -*-at top of files should be changed to<?php-- lending_requestremoveform() is a bad function name. lending_request_remove_form() is better.
-- More docblocks needed.
I would approve, granting the OP leeway to make these improvements.
Comment #9
sdague commentedJust removed the package declaration. That came from an example, and I didn't realize the full ramifications.
Comment #10
agentrickardBumping to see if anyone can approve.
OP is open and responsive to constructive criticism, too!
Comment #11
kreynen commentedHow is this different from any of the existing reservation/booking/lending modules?
http://groups.drupal.org/node/137544
I've installed the module. MERCI (http://drupal.org/project/merci) can be configured to do everything Lending does and already does a lot more.
A specific issue, the path to the admin settings menu should be admin/settings/lending, not admin/lending/settings.
Comment #12
gábor hojtsyI've approved the user for git access based on @agentrickard's feedback. Module differences can still be resolved.
Comment #13
sdague commented@kreynen, I installed and tried to use MERCI for this, but it's user interface is far too complicated for our users. There is a lot of business logic encoded in there about equipment checkout, and late fees, which don't really apply in our case. This is a largely non skilled set of users, for simplified set of user interaction points is very important.
Comment #14
kreynen commentedThis is probably moot since Lending is already written, but in the future it would be worth asking about simplifying a module before creating a new one. I'd really like to see a merci_simpler_ui module that would result in the same UI Lending has, but give users the option of expanding the functionality to do things I think are inevitable feature requests.
MERCI already had several submodules, but was recently broken up into several projects that simplify the core UI as well. Pricing has been moved to http://drupal.org/project/merci_pricing, Quota's to http://drupal.org/project/merci_quota, Email reminders to http://drupal.org/project/merci_email, etc.
The decision to break MERCI down further was based on feedback from users who had needs similar to yours. Simple MERCI installs are really a small number of implementations. The majority of MERCI users are public access stations and universities who use a lot of the functionality. I'm not saying that there should never be forking or multiple modules with similar functionality, but Lending is just one more module in a long list of booking/reservation/lending modules.
Inevitable feature requests...
- Show a calendar view of equipment requests
- Limit specific content type to a role beyond the LEND_ACCESS permission
- Request an item that is currently checked out
- See the status of several items at the same time... say I'm taking a group of kids out some night and need 3 telescopes. I'd like to see which 3 are available
You may never need any of that functionality for your group, but I can guarantee users will ask for those features since that's how MERCI got all the functionality it has. MERCI started as something almost as simple as Lending and grew organically over the last 2.5 years.
Comment #15
sdague commented@kreynen that's entirely possible. I didn't realize that the MERCI team would be interested in such an approach, because it looked like the major focus was on the more complex case. The fact that 12 of the 15 columns in the base merci_node_type table are related to pricing and checkout times makes it harder to think about adapting it, because none of those are valid questions in our case. If the hours and fees were broken out into a seperate module so that I wouldn't need to carry around that logic in the core merci, I can see how a simple UI on top of what remained would be interesting.
For right now I'm going to proceed on this module because we are starting to use it already, and the simple ui is really a key part of the feature. The person keeping track of things is going to doing so on his iPhone with the wheeled crate of DVDs that comes to each meeting, so minimum user interaction is really important. I will make sure to update the project description to point people at MERCI if their needs are more formalized. I'll also ponder a future possibility of attacking a simple ui on Merci.
Comment #17
PA robot commentedClosing due to lack of activity. Feel free to reopen if you are still working on this application (see also the project application workflow).
I'm a robot and this is an automated message from Project Applications Scraper.