-
-
Notifications
You must be signed in to change notification settings - Fork 41
Library Transaction Model
Many thanks to @corprew for piecing this together.
As these individual items are placed into separate Issues, I wanted to keep a holistic reference to the architectural design decisions.
This document gives an architecture and suggested behavior to add loaning carriers (assets) out to the babywearing site. This replicates some other library lending models.
The main transitions in the model is separating out "cart" and "item_loan" as concepts. Currently, there's always a cart attached to the loan, but that doesn't reflect the status of items.
Combine the Cart and Loan objects into a single model object named Loan.
The new Loan model object should have a reference to the member making the loan. The new Loan model object should have a property for returned_at, which will be set when a loan is returned.
The new Loan object should have two different volunteer associations, one for the volunteer who checks it in, one for the volunteer who checks it out.
The Loan object's status should be modified by checkout and checkin methods that encapsulate the desired behavior. checkout should take as parameters the volunteer who is checking it in and the due date (nil implies default), checkin should take as parameter the volunteer who is checking the object in.
Members should be able to add carriers to a 'watch list' of carriers that they are interested in. (This might need to be renamed.) This should create a Loan object with no volunteers or due date associated with it. This should be implemented as an action that creates the Loan and then redirects to the show page for the carrier if it succeeds.
Members must have signed the appropriate disclosures to check out items; if a member has not signed the required disclosures, they should be redirected to an information page for that.
When a volunteer looks at a detail page for a carrier, they should see a list of members who are interested in checking it out (who have a Loan object that has no checkout information.).
There should be a checkout button on each user in that list. When the volunteer clicks on that button, they should go to a separate action that confirms the volunteer wants to check out the Carrier to the member. It should also allow the volunteer to set a due date.
If the member already has too many items checked out for their membership type, they should receive an error with explanatory text instead.
At check out, the system should send mail containing information about the loan, including the carrier details and the information about when the carrier is due back.
This email must contain per-carrier safety information.
The system must send email reminding the member who checked out the information about the loan ### days before the loan is due.
This should be encapsulated in a job that is run daily.
The system must send a reminder about the carrier being overdue on the due date.
This should be encapsulated in a job that is run daily.
The system must periodically send mail (every ### days) reminding users that they have overdue carriers with information about the carriers and the due date.
When a volunteer looks at a detail page for a carrier that is checked out, they should see a view showing who has it checked out (current loan), and that view should have a link to allow the volunteer to start the checkin process on the item
When the volunteer clicks on that button, they should go to a separate action that confirms the volunteer wants to check in the Carrier. It should also remind the volunteer to collect any applicable fees.
After the volunteer checks in the carrier, the action should redirect back to the detail page for the carrier.
Volunteers and Admins should be able to see a list of users; Volunteers and Admins should be able to apply simple filters such as email or name to restrict the list of users. The list of users should appear either in the top icons or the list on the left as a link. This link should not appear to members who aren't volunteers or admins; this link should also not appear to non-logged in users browsing the site.
Volunteers and Admins should have an action that allow them to see a list signed-out carriers. A link to this list should be in the panel to the left in the current app, this link should not appear for members or non-logged in users viewing the site.
Volunteers and Admins should have an action that allow them to see overdue carriers. A link to this list should be in the panel to the left in the current app, this link should not appear for members or non-logged in users viewing the site.
This and the previous issue may optionally be the same action with a filter.
Add a view that lists the transactions that a member has done involving carriers. This page should have all the Loans where the member being looked at is the member in the Loan object.
If the user looking at the page has the role volunteer, they should be able to start the checkout process on carriers that the member they are viewing has indicated interest in.
If the user looking at the page has the role volunteer, they should be able to start the checkin process on carriers that the member they are viewing has checked out.
Add a view that lists the transactions that a volunteer has done involving carriers. This page should have all the Loans where the member being looked at is the volunteer who either checked in or checked out the Item.
If the user looking at the page has the role volunteer, they should be able to start the checkin process on carriers in the list that are currently loaned out.
Add a view that lists every loan that a carrier has been involved in.
If the user looking at the page has the role volunteer, they should be able to start the checkin process on the carrier if it is currently checked out.
If the user looking at the page has the role volunteer, they should see all the users who have indicated interest in the carrier — Loan objects that have not yet been checked out. They should be able to perform a checkout on one of those loans.
A volunteer of the system must only be able to checkout a carrier to a member if the member has fewer than membership_type.number_of_items currently checked out.
The user of the system should receive an appropriate error message if they try to check out more items than their membership type allows.
Split out the User class into separate User and Profile classes under the Single responsibility principle - Wikipedia.
User should only have the concerns related to authentication in it, that will allow us to later disable users and keep their historical data (what they borrowed and what they checked out) in the site.
This will have four parts:
- creating the class and its test infrastructure, moving the relevant properties from
UsertoProfile. - moving the associations related to app domain data from
UsertoProfile. - modifying the other files in
/app(and possibly other places throughout the rails app.) to look for the information in the new place.
In the current User schema, full_name, the address properties, and the phone_number should be moved to Profile