kexiaowen / pet-caring

CS2102-Group-8 (Pet Caring)

Table of Contents

• Project Requirements
• Instructions
• Appendix 1: Branching Workflow
• Appendix 2: Common Terminal Commands
• Appendix 3: Common Git Commands

Project Requirements

The system allows pet owners to search for care takers for their pet when they go out, travel or cannot take care of their pet for any reason. Both users and pets have a profile. Users of the service advertise their availability (when they can take care of a pet, for how long, the kind of pet they can take care of and other constraints and requirements) or browse and look for a care taker and bid. The care taker or the system (your choice) chooses the successful bid. Each user has an account. Administrators can create, modify and delete all entries. Please refer to dogvacay.com or similar sites for examples and data.

Instructions

Replace the petcaring folder in your local mappstack. Restart the server using manager-osx or Terminal, and go to localhost:8080/petcaring to see the site.

Note that to see other sites at the current moment, such as the search site, you have to manually proceed to localhost:8080/petcaring/<fileName> since routing has not quite been done yet.

To test for add, use pgAdmin 4 to visually check the data. Otherwise, use search to check for the data.

Remember to change the name of the database and the password!!

Appendix 1: Branching Workflow

This project uses a branching workflow, which essentially means that we should create a new branch every time we start work on a new feature/component.

The basic workflow can be summarised into the following steps:

1. Before starting a new feature, create a new branch

Go into the project directory using Terminal (and cd). Then, check that you are on the master branch by doing git status. If you are on the master branch, it will indicate that you are On branch master.

To create a new branch, do git checkout -b <branchName>, where <branchName> is the name of your new branch. It is recommended that you name the branch descriptively, i.e. related to the feature that you are currently working on. Note that a new branch with <branchName> will be created, and you will automatically be switched from the master branch to the <branchName> branch.

Note also that if you do this on another branch aside from the master branch, say, branch search, your new branch will include all the changes in branch search as well, which is probably not what you wanted.

2. Make changes within your local repository, and commit the changes

Make changes you need on the <branchName> branch. Add the changes by doing git add <fileName> or git add * (if you want to add everything), followed by git commit -m "<commitMessage>" to add a descriptive and short commit message for your changes. Alternatively, do git commit, then press a to enter INSERT mode before keying in your commit message. Exit INSERT mode by doing ESC, then :wq.

3. Push the branch to the remote repository

To push the branch to the remote repository, do git push origin <branchName>, or do git push -u origin <branchName>. The second option allows you to simply do git push without any parameters the next time you want to push the same branch to the remote repository.

4. Open a pull request

Proceed to GitHub, find your branch, and open a pull request. Wait for your group members to see, check and test your changes, before merging the branch into the remote repository.

5. After a successful merging, delete unwanted branches

After the branch has been merged successfully into master, the branch is now essentially useless and can be deleted. Delete the branch on the remote repository via GitHub. To delete the branch on your local repository, go to the Terminal, switch back to your master branch by doing git checkout master, and delete the branch by doing git branch -d <branchName> followed by git branch -D <branchName>.

6. Update your local repository

To sync your local repository with the remote repository, do git pull while on the master branch.

Appendix 2: Common Terminal Commands

• cd <folderName> : change directory (folder) into another folder
• cd ../ : go back to the outer folder
• cd : go to the root
• ls : see the files and folders in the current directory

Appendix 3: Common Git Commands

• git status : check what branch you are on, what files are being tracked, and ready for commitment
• git log : show commit history for a branch
• git log --graph : show commit history for a branch in a nicer way
• git checkout <branchName> : switch to an existing branch
• git checkout -b <branchName> : create a new branch and switch to that branch
• git branch : lists branches in your local repository
• git branch -v : lists branches with latest commit details in your local repository
• git branch -d <branchName> : delete a branch
• git add <fileName> : stage files for commit
• git commit <fileName> : commit files
• git commit <fileName> -m "<someMessage>" : commit files with short commit message
• git push origin <branchName> : push a branch to the remote repository
• git remote : see all remotes
• git remote -v : see all remotes and the remote repository each remote is pointing to
• git pull : sync local repository with remote repository (auto merging of changes in remote repo with local repo)
• git fetch : get changes in remote repository without merging into your local repository

pet-caring's Issues

Issue with editing pet details

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.

Issues with Schema bid table

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?

Implement search page

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.)

Flaws in availability data

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?

Problem with current availability data values

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".

View for my bids

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?

Implement homepage, sign up, log in and (person) profile pages

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.)

Implement my availabilities page

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.)

To do: Ensure that rejections are reflected in bids page

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

Issue with adding an added bid

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).

Insert availability and bid data

// 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');

Implement pet profiles (my pets) and my bid pages

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.)

Problem with Schema for bid table

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?