Zen Cart Gift Registry 05.02.08
This project is for the completion of a zen-cart wedding registry system.
FRONT END
An order can only be for a customer themselves, or for one single gift registry. An order can never be mixed between personal items and registry items, nor can an order contain items from different registries. This is done for simplicity of design.
Orders for registries must place extra data into the orders table of the database. This includes the name of the parties involved, the identifier of the registry, and the occassion type. This data must be viewable on the order history page of a customer. The items are placed in there in text instead of using id numbers incase a registry is deleted so the information about an order can be retrieved in the future.
The customer must never see the address of a registry recipient, yet this is the default shipping address of registry orders. A shipping module is assigned to registry orders (in other words, this module is always used to ship registry orders). So the price should be calculated using the registry recipient’s address and the registry shipping module. The default shipping module should be a configuration setting. How that configuration setting can be implemented can be discussed.
When an order is placed successfully it needs to update the registry fields accordingly. Examples of these fields are purchased and needs. A registry gift recipient requests a certain number of an item, and then the number of items is deducted from how many they need to form a new needs number. The system must never allow somebody to purchase more of an item than a recipient needs.
There is a bridal registry link at the top of the page. This needs to lead the user to a place where they can search for the registry they are looking for. They should be able to search on first or last name and the system should find any matches on that input. Upon clicking a link the user will be directed to a page where the products the registry recipient needs are listed. See www.branchhome.com for an example of what I will expect. An addition to this though is an image. Each registry has an image associated with it and must be displayed on that page.
The graphic design of the front end must be completed to match the top and bottom of the site. Also, the broken images need to be fixed. The images for all of the products and current registries are present however some are not linked correctly in the database.
The branch home site also has a create registry functionality. You need not implement this since all registries will be added from the admin, but please be mindful in your design that this might be a feature added later.
ADMIN
There are six pages in the admin that need to be fixed. They are view registries, add a new registry, view products in a registry, add new product to a registry, edit a registry, and delete a registry. The pages are there already but do not work. They were taken from a previous system and need to be updated to use the current one. Thumbnails in the admin must not simply be the images scaled down, they must be new, cached, resized images, just as the front end does it. This is for asthetic purposes.
The view registry page needs to add a piece of functionality. Registry will need another field in the database to be added called “active” which will initially be set to 1 for all registries. The user will then need to be able to set a registry to “inactive” (or 0 in the database) and the filter should include the ability to filter by “All” (0 or 1), “Inactive” (0) or “Active” (1).
The rows of all the tables must alternate in color as well.
Once you begin you will have one week to complete the project. Time is of the essence. Serious bids only by serious programmers.
