kexiaowen / pet-caring Goto Github PK

Some basic guidelines:

Homepage for users who have not logged in:

• Set up correct routing to respective pages in the NavBar (home, login, signup)
• Check and redirect users who have not logged in but pressed the Be a pet carer button to the login page

Homepage for users who have logged in:

• The NavBar can be personalised to say "Hi [name]
• NavBar should include ways to access Log out, My profile, My availabilities, My pets and My bid

signup:

• Should have all the fields corresponding to table schema
• Nearing the end of the page, have a line that says Already have an account? Log in where "Log in"has a hyperlink to the login page

login:

• Should have fields for email and password
• Nearing the end of the page, have two lines as follow:
  (i) New user? Sign up
  (ii) Log in as Admin? Click here
  where "Sign up" links to the signup page and login links to the login page

profile:

• Should display these editable fields: name, password, and address-related fields (region, address and postal code
• Should allow these fields to be edited and updated

**IMPORTANT: Trim whitespace for all forms implemented, and pre-fill fields for all forms (if logged in/ searched something previously etc.)
Note that these are just guidelines, and the person implementing should adjust and adapt accordingly (layout/content etc.)

Right now, editing pet details is disabled after the owner has submitted at least one bid for the pet. However, the pet should be open for editing again after all bids for the pet has been rejected.

Some basic guidelines:

my pets:

• Card format that displays all the pet profiles of the pets owned by a person
• All pet details of each pet should be fully displayed on each card (refer to schema)
• Should allow each card to be edited
• Should allow each card to be deleted

my bid:

• can possibly adapt my availabilities page

**IMPORTANT: Trim whitespace for all forms implemented, and pre-fill fields for all forms (if logged in/ searched something previously etc.)
Note that these are just guidelines, and the person implementing should adjust and adapt accordingly (layout/content etc.)

Some basic guidelines:

my availabilities:

• Availabilities are presented in card format, and ordered by start date
• Each card shows all the details for an availability (see schema), and also the bid count
• Each card indicates the status of the availability (can be colour change/ explicitly stated/ both)
• Allow availability to be edited or deleted
• Once an availability is accepted, disable edit and delete for the availability

**IMPORTANT: Trim whitespace for all forms implemented, and pre-fill fields for all forms (if logged in/ searched something previously etc.)
Note that these are just guidelines, and the person implementing should adjust and adapt accordingly (layout/content etc.)

Currently, the view_bids.php is accessed via either the navbar or the availability page. However, accessing it via the navbar shows nothing since no information is sent there (unlike in the case of the availability page. Should we remove the link from the navbar, or just create another page where the navbar link shows ALL bids for the current user, regardless which availability?

I found some issues with our availability data while I was trying to test my new page. There are some data which have end_date being even earlier than start_date, which makes no sense at all. For example, in line 115, we have this:
INSERT INTO availability VALUES ('2017-01-22', '2017-01-17', 'hamster', '[email protected]', 10, FALSE);
which is ??

Is it possible to look into this?

Some basic guidelines:

search:

• Should allow four fields to be searched: Start date, End date, Type of pet, and Max bid
• Updating results of the search should be done by AJAX as far as possible (i.e. not reload the entire page)
• Results should be returned in card format, and display details about matching caretakers
• A user can then input a bid amount before Add bid
• If the user is logged in, the bid will be added
• If the user is not logged in, redirect the user to the login page
• Assume that user will only place 1 bid for a single caretaker for each type of pet/date

**IMPORTANT: Trim whitespace for all forms implemented, and pre-fill fields for all forms (if logged in/ searched something previously etc.)
Note that these are just guidelines, and the person implementing should adjust and adapt accordingly (layout/content etc.)

XW:

1. I am currently working on the accept bid function and realised that our primary key for pet is pet_name + owner. I feel this means that when the user place a bid, user should specify the pet name (which pet he wants the caretaker to take care of, as he might have 2 hamsters). Otherwise in the accept bid page, i won't be able to identify the pet and display relevant data.

Summary : i think bid table should include one more attribute pet_name and pet_name is a foreign key and part of primary key.

2. bid table should include one more attribute accepted (boolean) to indicate whether the bid is successful ?

JO:
3. Adding on to issues, I realised that our schema for the bid table also has other fatal flaws (which caused me much unnecessary grief).

Notice that we have this:

FOREIGN KEY (caretaker, start_date, end_date) REFERENCES availability(caretaker, start_date, 
  end_date) ON UPDATE CASCADE ON DELETE CASCADE

in the schema for the bid table. However, right now, our search is implemented such that the start date and end date used for the search does not have to be the exact start date and end date of the availability of the pet owner, whereas our schema demands an exact overlap. For the time-being, I have just ignored the issue for now, but this is definitely something we need to discuss again. The easy way out is of course, to just allow for an exact overlap, though that would be less realistic.

What do yall think?

Currently, the search page will still display availabilities for which the user has already bid for previously. To prevent this from happening, we can complicate the search query (e.g. by adding a WHERE NOT EXISTS in bid table).

The current values of start and end dates that we insert into the availability table are not realistic. We need to change the date to more recent values. This is stated in the requirements for alpha demo - "100 realistic items".

As I was creating the add function for the bid table, I realised that our Schema for the bid table is:

CREATE TABLE bid (
	price integer NOT NULL,
	bidder VARCHAR(355),
	caretaker VARCHAR(355),
	start_date DATE,
	end_date DATE,
	FOREIGN KEY (caretaker, start_date, end_date) REFERENCES availability(caretaker, start_date, end_date) ON UPDATE CASCADE ON DELETE CASCADE,
	PRIMARY KEY (bidder, caretaker, start_date, end_date)
);

And I felt that a bidder should REFERENCE the account table since it does not make sense for a bidder to be able to bid without having an account with our system.

What do you guys think?

// Example of an availability record
// 1. Start date must be earlier than end date!!!
// 2. Better to have more recent dates ranging from 2017-10-01 to 2018-02-28
// 3. animal types must be lowercase 'dog' 'cat' 'bird' 'rabbit' 'hamster'
// 4. Legitimate remarks please
// 5. About 150 records.
// 6. For the same caretaker, e.g. [email protected], cannot have 2 availabilities with overlapping date ranges
// This means cannot have 1 availability with caretaker = '[email protected]' start_date='2017-10-03' end_date = '2017-10-06'
// and another availability with caretaker = '[email protected]' start_date='2017-10-05' end_date = '2017-10-10'
INSERT INTO availability VALUES ('2017-11-12', '2017-11-14', 'cat', '[email protected]', 10, FALSE);
INSERT INTO availability VALUES ('2017-12-24', '2017-12-25', 'dog', '[email protected]', 10, FALSE, 'I have taken care of three dogs previously.');

// Example of a bid record
// (price, accepted_bid, bidder, caretaker, pet_name, start_date, end_date)
// 1. Respect foreign key constraints
// Check the data are ok by running all the table creation and insertion statements on pgAdmin!!
INSERT INTO bid VALUES (15, FALSE, '[email protected]', '[email protected]', 'Bean', '2017-11-12', '2017-11-14');

Right now, if the caretaker accepts an alternative bid, the bids table and bids page will not reflect this.