These "extension" stories are for the final week solo project for Backend Module 2 students.
You are required to complete the feature Users Have Multiple Addresses. You may choose to complete any number of the additional extensions listed.
For each feature, you'll see Completion Criteria and Implementation Guidelines. The Completion Criteria are the points that instructors will be assessing to ensure you've completed the work. The Implementation Guidelines will direct you in how to implement the work or offer advice or restrictions.
You get to choose how to implement the story, presentation, routing, etc, as long as your work satisfies the Completion Criteria.
- Fork this repository
- Clone your fork
- When you are finished, push your code to your fork.
Users will have more than one address associated with their profile. Each address will have a nickname like "home" or "work". Users will choose an address when checking out.
- When a user registers they will still provide an address, this will become their first address entry in the database and nicknamed "home".
- Users need full CRUD ability for addresses from their Profile page.
- An address cannot be deleted or changed if it's been used in a "shipped" order.
- When a user checks out on the cart show page, they will have the ability to choose one of their addresses where they'd like the order shipped.
- If a user deletes all of their addresses, they cannot check out and see an error telling them they need to add an address first. This should link to a page where they add an address.
- If an order is still pending, the user can change to which address they want their items shipped.
- Exisiting tests should still pass. Since you will need to make major changes to your database schema, you will probably break many tests. It's recommended that you focus on the completion criteria described above before going back and refactoring your code so that your existing tests still work.
- Every order show page should display the chosen shipping address.
- Statistics related to city/state should still work as before.
Merchants can generate coupon codes within the system.
- Merchants have a link on their dashboard to manage their coupons.
- Merchants have full CRUD functionality over their coupons with exceptions mentioned below:
- merchants cannot delete a coupon that has been used
- merchants can have a maximum of 5 coupons in the system
- merchants can enable/disable coupon codes
- A coupon will have a name, and either percent-off or dollar-off value. The name must be unique in the whole database.
- Users need a way to add a coupon code when checking out. Only one coupon may be used per order.
- Coupons can be used by multiple users, but may only be used one time per user.
- If a coupon's dollar value ($10 off) exceeds the total cost of everything in the cart, the cart price is $0, it should not display a negative value.
- A coupon code from a merchant only applies to items sold by that merchant.
- Users can enter different coupon codes until they finish checking out, then their choice is final.
- The cart show page should calculate subtotals and the grand total as usual, but also show a "discounted total".
- Order show pages should display which coupon was used.
- If a user adds a coupon code, they can continue shopping. The coupon code is still remembered when returning to the cart page.
- Database relationships and migrations
- ActiveRecord
- Software Testing
- HTML/CSS layout and styling
Merchants add bulk discount rates for all of their inventory. These apply automatically in the shopping cart, and adjust the order_items price upon checkout.
- Merchants need full CRUD functionality on bulk discounts, and will be accessed a link on the merchant's dashboard.
- You can choose what type of bulk discount to implement: percentage based, or dollar based. For example:
- 5% discount on 20 or more items
- $10 off an order of $50 or more
- A merchant can have multiple bulk discounts in the system.
- When a user adds enough value or quantity of items to their cart, the bulk discount will automatically show up on the cart page.
- A bulk discount from one merchant will only affect items from that merchant in the cart.
- A bulk discount will only apply to items which exceed the minimum quantity specified in the bulk discount. (eg, a 5% off 5 items or more does not activate if a user is buying 1 quantity of 5 different items; if they raise the quantity of one item to 5, then the bulk discount is only applied to that one item, not all of the others as well)
- When an order is created during checkout, try to adjust the price of the items in the order_items table.
- Database relationships and migrations
- Advanced ActiveRecord
- Software Testing
- HTML/CSS layout and styling
Merchant dashboards will display a to-do list of tasks that need their attention.
- Merchants should be shown a list of items which are using a placeholder image and encouraged to find an appropriate image instead; each item is a link to that item's edit form.
- Merchants should see a statistic about unfulfilled items and the revenue impact. eg, "You have 5 unfulfilled orders worth $752.86"
- Next to each order on their dashboard, Merchants should see a warning if an item quantity on that order exceeds their current inventory count.
- If several orders exist for an item, and their summed quantity exceeds the Merchant's inventory for that item, a warning message is shown.
- Make sure you are testing for all happy path and sad path scenarios.
- MVC and Rails development
- Database relationships and migrations
- ActiveRecord
- Software Testing
Feature Completeness | Rails | ActiveRecord | Testing and Debugging | Styling, UI/UX | |
---|---|---|---|---|---|
4: Exceptional | One or more additional extension features complete. | Students implement strategies not discussed in class to effectively organize code and adhere to MVC. | Highly effective and efficient use of ActiveRecord beyond what we've taught in class. Even .each calls will not cause additional database lookups. |
Very clear Test Driven Development. Test files are extremely well organized and nested. Students utilize before :each blocks. 100% coverage for features and models |
Extremely well styled and purposeful layout. Excellent color scheme and font usage. All other rubric categories score 3 or 4. |
3: Passing | Multiple address feature 100% complete, including all sad paths and edge cases | Students use the principles of MVC to effectively organize code. Students can defend any of their design decisions. | ActiveRecord is used in a clear and effective way to read/write data using no Ruby to process data. | 100% coverage for models. 98% coverage for features. Tests are well written and meaningful. All preexisting tests still pass. | Purposeful styling pattern and layout using application.html.erb . Links or buttons to reach all areas of the site. |
2: Passing with Concerns | One of the completion criteria for Multiple Address feature is not complete or fails to handle a sad path or edge case | Students utilize MVC to organize code, but cannot defend some of their design decisions. Or some functionality is not limited to the appropriately authorized users. | Ruby is used to process data that could use ActiveRecord instead. | Feature test coverage between 90% and 98%, or model test coverage below 100%, or tests are not meaningfully written or have an unclear objective. | Styling is poor or incomplete. Incomplete navigation for some routes, i.e. users must manually type URLs. |
1: Failing | More than one of the completion criteria for Multiple Address feature is not complete or fails to handle a sad path or edge case | Students do not effectively organize code using MVC. Or students do not authorize users. | Ruby is used to process data more often than ActiveRecord | Below 90% coverage for either features or models. | No styling or no buttons or links to navigate the site. |