Some important details that everyone missed

One of the more complex parts of the freecycling problem is selecting a recipient and scheduling the transfer. The state-transition diagram below illustrates the key steps in this process.

The diagram has the following states:

• Posted The offer to donate is posted to the site, potential recipients can express interest.
• Pending The donor has selected a recipient and has begun the process of scheduling a transfer meeting. New potential recipients can still express interest.
• Scheduled The transfer meeting has been scheduled. New potential recipients can still express interest.
• Done Exchange has taken place.

To model these states you will need to add a state field to the offer table in your database if you have not already done so.

The diagram includes these transition actions

• Select Donor selects a recipient
• Schedule Transfer time and place reserved (Meeting saved in database)
• Complete Exchange completed (Offer, bids, and schedule removed from database)

You will need to set up a controller method somewhere in your application for each one of these actions.

The part that almost everyone missed in their initial design was anticipating all the things that could possibly go wrong. The next diagram adds additional transitions to model each of those things.

The additional transitions I added are meant to model all of these things:

• Deselect Donor unselects recipient (Any meetings associated with this transfer are removed).
• Withdraw Recipient withdraws interest. (Their interest is removed from the database, any scheduled meetings are cancelled.)
• Deschedule Meeting is cancelled, recipient is retained.

Finally, there is one last action that isn't represented in the diagram.

• Cancel Donor withdraws offer (All interest and schedule entries for this offer are removed.)

You will need to set up a controller method somewhere in your application for each of these actions.

Messaging

One feature of all of the actions listed above is that they can be performed unilaterally by one of the two parties. When that party triggers the action the polite thing to do is to inform the other party that the change has taken place. For example, if the recipient cancels the meeting we should send a message to the donor to let them know that this happened.

This suggests very strongly that we need to add a messaging system to our application, along with methods to generate, read, and delete messages. You can also use the messaging system as a mechanism to negotiate potential meeting times for transfers.

Building out the system

Your assignment now is to integrate these changes into your design and to build out your system.