harmonickey / enhabit Goto Github PK

We need to have a standard feature for people to be able to sign in securely.

They should be able to sign in with their Facebook accounts as well.

I think having the account information should be in a separate table/collection because of the one-to-many relationship with one account having many apartment locations. I could see a single landlord have one account but list 20 apartments.

We should then have the apartment information in a separate table/collection where they each have a key field that points to their associated account.

@Saurutobi I would like to hash this out in more detail once we know exactly the sorts of fields we're dealing with.

At the moment we have cookies expiring on the client side no problem and they will work by communicating with the server side and allowing for credentials to be used, but credentials are never passed to client side (for safety). However, there is no way at the moment to delete old cookies on the server side.

In addition, @Saurutobi @justinpituch @SKdaedalus what do we think about the expiration for cookies (i.e. how long a user can stay logged into the website)? At the moment, it is defaulted to 7 days. However, it might be better to be 1 day.

(BRANCH): enhabit/images/59

(DESCRIPTION): I think it will be an overall advantage to move the images to a different location on disk. Having them in the git repo is just trouble. I don't want to deal with merge conflicts on the server after a webhook activates, so I basically do a full clean and then pull which removes all the images. I cannot do a gitignore on it because of the full clean. In addition, image retrieval is somewhat slow because we are not retrieving from another domain. Browser rules say that if multiple resources are on separate domains, the browser will fetch them concurrently as opposed to sequentially as normal.

I think setting up a subdomain that can be used for multiple sites will be useful. images.lbkstudios.net under it will be directories like 'enhabit' which will then have their own separate uses. 'enhabit' will have the upload_file.php function as well as the delete_file.php function. There will be a single images directory or something.

(ACCEPTANCE CRITERIA):

1. images.lbkstudios.net setup
2. image php functions setup
3. file upload and deletion still work
4. upload_file.php and file locations updated in current code

(PARENT TICKET): none

(DEPENDENT TICKETS):none

(BRANCH): ferrari/reorganize/40

(DESCRIPTION):
Right now each individual section has its own assets folder essentially. So we have multiple jquery libraries, among other files. The only thing that would conflict is the functions.js files, which we would simply name as their section, so "listings.js" or "admin.js"

However, all the other tickets need to be completed first so that I can reference them in a new branch off of master.

(COMPLETION REQUIREMENTS):

1. All library files are moved to /libraries
2. All css files moved to /styles
3. All js files moved to /js
4. All ui files reference their respective assets in the new location
5. function.js files are renamed to their respective section.

(PARENT TICKETS): none

(DEPENDENT TICKETS): none

(BRANCH): (tbd)

(DESCRIPTION): When users create listings, they need to select from a list of landlords so that the entity is associated. When admins create listings, they need to select from a list of users and a list of landlords for the listing. When landlords manage their renters, they are really getting a distinct list of users that result from querying listings that matched the landlord field. When landlords manage listings, they should be getting all entities that match on the landlord field.

(COMPLETION REQUIREMENTS):

1. Dropdown list populated with current Landlords (queried from users table, with landlord filter) for create listings view (Hummer)
2. Dropdown list populated with current Users and current Landlords for create listings view (Bmw)
3. Managing Renters for landlord view shows users that hold properties (this is clearly different from listings, since they might be currently living there but not necessarily listing their place for search...)? So this would be users that have already listed once, and then actually got the new place. This also assumes that the user created an account with us in the first place and THEN got the place, through us, but they don't necessarily have to.
4. Managing Listings for landlord view shows listings that the landlord current is associated with.

(PARENT TICKET):none

(DEPENDENT TICKETS):none

1. Create Repo for Enhabit
2. Download Twilli wrapbootstrap template
3. create hook to bluehost from github repo master branch
4. Upload into repo
5. remove all unneeded template stuff (keep things like modal support, background support, and most of the css/sass/less)
6. remove the multiple sections of the main page
7. add in the mapbox to be the background of the main page
8. create mongodb database on bluehost
9. insert fake data into mongodb database (5 at least)
format is {username: alex, address: 2060 Ridge Ave, bedrooms: 2, price: 750 } (need to talk to @justinpituch about all the parameters that will be useful)
10. create commands for mongodb to filter data based on certain parameters
11. create buttons that access functions on web site left hand sidebar
12. take results from buttons and insert into mapbox api to filter on UI

(BRANCH): hummer/listings/26

(DESCRIPTION): The listings need to be filterable (by sidebar query), listed in list view, edited(updated) by their users, deleted by their users, and created anew in the separate portal. The portal will be an admin-like portal that is used by both leasers and renters.

The user (and by extension, the landlord) should be able to login through this hummer portal. However, if they login through Mercedes, they should still be able to access hummer without having to login again. The connection point is clicking "Manage Listings" on Mercedes.

(COMPLETION REQUIREMENTS):
1. Hummer portal (used by both landlords and users).
2. Hummer portal separate tabs for either landlord or user.
3. Listings can be created, read (viewed), edited (updated), and deleted.
4. User can login through Mercedes and get to Hummer by "Account/Listings"
5. User can login through Hummer by going to /listings
6. Any user (logged in or not) can view all the current listings in Mercedes in a list view with details.
7. Remove Listings creation from Mercedes
8. User and Landlord can manage account info
9. Account info is removed from the front page

(PARENT TICKET): none

(DEPENDENT TICKETS): #16

(BRANCH): hummer/create-listing/14

(DESCRIPTION): I am going to move the open script tag code in the index.html file to be in its own file. That way the rest of the page can load without being blocked by mapbox calls.

This occurs starting on line 246 of index.html

(COMPLETION REQUIREMENTS):
1. Unused functions and javascript files are removed.
2. Javascript from main page is removed or at least put at the end of index.php.
3. Loading is noticeably faster.
4. Chrome Profiler shows a quicker loading time.

(PARENT TICKET): #14

(DEPENDENT TICKETS): none

(BRANCH):mercedes/filtersux/68

(DESCRIPTION):When I clicked the Extra Filters button, the UI glitches and Expands. This is a problem with the timing of the expansion.

(ACCEPTANCE CRITERIA):

1. No glitching on expansion.
2. Timing and UX is the same as expansion

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH):none

(DESCRIPTION):Alex is sending out a Scheduler thing, and then we'll vote on here and figure it out.

(COMPLETION REQUIREMENTS):Have a weekly Hangouts call scheduled

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH):ferrari/mongodb/37

(DESCRIPTION):Add MongoDB info files to Repository so we can create a new db right from the repository if need be.

(COMPLETION REQUIREMENTS):MondoDb files added

(PARENT TICKET):none

(DEPENDENT TICKETS):none

I think we should start with this template. It's clean, easy to manipulate and comes with a good amount of stuff that will be useful later when we add plugins and stuff. I think it's worth the $10 for the amount of coding and design work time that it'll save. Most of the hardcore coding will come later, but this could put us off to a good start.

https://wrapbootstrap.com/theme/twilli-air-minimalist-one-page-theme-WB0196957

We could then replace the default background with the mapbox api.

https://www.mapbox.com/industries/realestate/

We can then go from there by adding in the filters for getting a subset of points to pop up on the map.

When window is smaller the sidebar reverts to a different html set which doesn't have the css attached that made the previous sidebar appear above the map. Currently it is behind the map.

The fix is to make the other sidebar have the css value
z-index: 1

That should fix it.

(BRANCH): mercedes/fit-bounds/34

(DESCRIPTION): It would be convenient to zoom out/in the map enough automatically to encompass all the current pins on startup. I can imagine a larger campus that has multiple areas of rentals, so we'd want to show them all, for the university, if possible.

https://www.mapbox.com/mapbox.js/example/v1.0.0/fit-map-to-markers/

(COMPLETION REQUIREMENTS):
1. Zoom out/in to encompass all university pins

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH): hummer/applicants-renters/93

(DESCRIPTION):
I think the best way to go about this would be to create a whole separate renters table. Essentially, once a user has gone through the whole process and signed their lease with the landlord, they get put into the Renters collection. In this collection we'd have information like amount due (rent amount), amount paid, lease expiration, address, first name, last name, phone number, email, stripe account user (?)

Even though technically it is a part of hummer, we are not entirely sure how this is going to pan out, so I won't connect them through parent/dependent at this time so that #26 can push through.

(COMPLETION REQUIREMENTS):

1. Collection that has all of these fields.
2. Ruby script that creates the contract (interface) for these fields. It will be kept in a new Core library called Renters.
3. Simple CRUD for the renters collection.
4. Documentation on 'columns' used in /Database/[tablename]-Columns.txt

(PARENT TICKET): none

(DEPENDENT TICKETS): none

I think we should come up with cool codenames, or at least some girls' names for each of the big items in this project.

Payments system:
Maps/Finder:
Leaser Hub:
Renter Hub:
Web Services/Server:

I want to name one of the Lilly because I can't get that name out of my head.
basically, instead of saying enhabit/payments/23 it could be codename/23 or enhabit/codename/23, and when we talk to each other it wouldn't be "payments is having x problem" it would be something like "I found a bug in [codename]. x is not working".

(BRANCH):facebook-login/15

(DESCRIPTION):Need to allow users to have an account through us that authenticates through Facebook.

1. Get Facebook Login API
2. Put button in login modal
3. Retrieve login information on callback and handle as login info
4. If user doesn't exist, create a new one, otherwise just login
5. Make sure sessions work correctly
6. Make sure it works when the user is not necessarily logged into Facebook at the moment.
7. Add update account feature

(COMPLETION REQUIREMENTS):Listed in Description

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH): mercedes/sidebar/66

(DESCRIPTION): The sidebar should look like the attached image, it will be more organized and readable for the users to use (ideally). In addition, it places more emphasis on search, which is particularly important.

(ACCEPTANCE CRITERIA):

1. Site matches mockup.
2. No functionality is broken.

(PARENT TICKET): none

(DEPENDENT TICKETS):none

This should be some sort of web service that an application can connect to and get back data from our mongodb database.

There should be a key of some sort that is used in order to get sensitive information. Luckily though, mongodb is not 'injectable' like SQL is because we are using a ruby mongo library which protects against that.

For now I would like to use Sinatra, it is a lightweight and super easy REST service.

I'll just set it up for now with skeleton code and we can add more to it later.

Should be run by, not sure how we'll maintain it so that it'll always be on. The exception handler helps, but the servers get restarted every once in a while. We may need to run a cron job on the server that checks for the process. We'll probably use an awk bash script.
$> ruby web-service.rb

For safety, we need to set the read/write/execute permissions to user-only (chmod 700), otherwise you could just type test.lbkstudios.net/web-service.rb and see what's inside (mongo instance, keys, etc).

(BRANCH):mercedes/sidebar/5

(DESCRIPTION):This sidebar should have functionality that includes the filter functions at least. Later we'll add things like the marketplace stuff and the bill paying stuff.
Each should have an ID that can be grabbed by the filtering query
Price: Doublenode slider
Bedrooms: number dropdown
Bathrooms: number dropdown
Animals Allowed: yes/no
Laundry in Unit: yes/no
Parking: yes/no
Available starting on: date selector
Tags: Text box with tag selectors
Rental or Sublet
No scrolling or dragging on filter views
Normal cursor when on filter views
Remove Extra Twili files and backedup in Dropbox
Make sure Twili is in LbKStudios Dropbox file for safe-keeping
All Yes/No fields must have dropdown selector with "both/any" option is included and defaulted.

(COMPLETION REQUIREMENTS):Filters in sidebar working and building proper query. Twili backed up and weeded out.

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH): bmw/28

(DESCRIPTION): Right now the user logs in and the $_SESSION tenant/landlord and userId variables are set. The only way to get to our API is to have tenant or landlord session variable set. It does not require that userId is set. UserId is currently exposed on the frontend by echoing to a javascript variable. In the worst case, someone wouldn't need to know the username and password of someone, but just go to their computer and see the userId in the javascript source. They could then login as their own user and insert the userId of another user into the ajax request.

There needs to be an auth script that checks to make sure that the information (userId probably) matches with the session variable (tenant or landlord). It would return a truthy value which I could use to execute or not execute the api script. This would prevent deletion of listings and accounts.

What might be better is to use UserId in the php only and never expose in the javascript. I may be able to do this, I don't remember why I took it out in the first place.

(ACCEPTANCE CRITERIA):

1. No security leaks with api. No User can modify any other user's data.
2. Full login on all 'sites' that can be accessed(like tenant and such)

(PARENT TICKET): #28

(DEPENDENT TICKETS):none

(BRANCH):none

(DESCRIPTION):Get a Client, and get their data in the system and showing nicely. Charge them appropriately.

(COMPLETION REQUIREMENTS):Filterable, clean, good data. Charged

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH):none

(DESCRIPTION):We need to figure out what our destination payments location will be.

(COMPLETION REQUIREMENTS):figure out destination payments plan.

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH): hummer/listings/46

(DESCRIPTION):
The user should be able to upload pictures for their listing. This includes a filesystem location as well as source references in each listing document (row) in the mongo collection (table).

(COMPLETION REQUIREMENTS):
1. User can upload listing pictures in both tenant and landlord locations.
2. Listing is reflected by correct source locations in source array
3. Image sources for listing are loaded into front page.
4. User can view/delete pictures with each of their listings.

(PARENT TICKET): #26

(DEPENDENT TICKETS): none

(BRANCH):bmw/errors/49 (To be Created)

(DESCRIPTION):We need a way for Admins to track and view errors and occurrences so we know what's going on.

(COMPLETION REQUIREMENTS):

1. Create "Errors" database Table
2. Create a list of Exceptions that all Errors must map to. Stuff like "Null Exception" "Application Exception" "Invalid Argument Exception" etc. This way we can query based on Exception type. This list will go in a new Wiki page called Exception Types
3. Create a page in the Admin site to display the errors.
4. Across All Files, wherever an Error occurs(even if you don't display a message to the user), make an entry into the database. This would be just an async call to ErrorHandler.php which will make the entry. Information required: Date, SessionId(Guid that identifies unique sessions. This will also be used for Tracking later.). Error Message(string), Error Type(number), FrontFacing Page(so we know where it came from), Backend File(so we know what file threw the error). If an error occurs in the javascript, the Backend File column would be null.
5. Extract $.msgGrowl error messages into a single method which accepts the message so a single error-display fix will apply to many situations.

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH): mercedes/tags/63

(DESCRIPTION): I was thinking that this popup should actually show like "top tags used at Northwestern University" or something. I can do a simple aggregate query on mongodb (that's what it's built to do well) and get counts. That way, it can be shown what the users can possibly use in their search queries for tags. It might help the users create listings with smarter tags too.

(ACCEPTANCE CRITERIA):

1. Shows more relevant data

(PARENT TICKET): none

(DEPENDENT TICKETS):none

(BRANCH):bmw/28

(DESCRIPTION): We should have a secret site where we have access to all administrator-type things.

(COMPLETION REQUIREMENTS):

1. Manage Users: Add (also be able to make landlord), Delete, Update(also be able to make Landlord). Validation for all data.
2. Manage Listings: Add, Delete, Update. Validation for all data.
3. Payments: View all transactions going through EnHabit. Filter by types of transactions(PPC, featured, Bills, Ads).
4. Site-wide Analytics. PageViews, Click Data, and Session Tracking
5. When updating/creating listings there needs to be a dynamically loaded list of landlord names and user names so that the admin can select between them. The update/create validation should require that either one or the other is necessary, but you cannot submit with neither.
6. Confirm that everything in Core and Admin is consistent with https://github.com/Harmonickey/EnHabit/wiki/MongoDB-Collections,-Indices,-and-Keys

(PARENT TICKET):none

(DEPENDENT TICKETS): #33 #47

The context for this is when a user is putting up their place for rent or whatever through the site.

I think we'll actually need to use GoogleAddressSearch for this part. When people search for their address when creating the account, a dropdown list of the possible addresses should pop up and they would click on the right one. Google would give back the lat and long of the address in question and then we'd be able to add a marker to our map with mapbox, as well as adding it into the mongodb database for future use.

Otherwise, when loading data, the front end will query all address within the box of the screen and then insert markers into the map that way.

(BRANCH):hummer/create-listing/14

(DESCRIPTION):
Can we nail down a proper width and stick to that?
It looks really weird when I'm playing around with the width.

If so, it needs to be just wide enough for the footer not to word-wrap(the second line all on one line), but not really any more than that.

I like that the sidebar snaps away into a menu bar tho at a certain width.

(COMPLETION REQUIREMENTS): Sidebar width static

(PARENT TICKET):#14

(DEPENDENT TICKETS):none

(BRANCH):hummer/create-listing/14

(DESCRIPTION):
The user should be able to create a simple listing of their apartment after logging in.

If so, it needs to be just wide enough for the footer not to word-wrap(the second line all on one line), but not really any more than that.

I like that the sidebar snaps away into a menu bar tho at a certain width.

(COMPLETION REQUIREMENTS):
1. Create new popup modal
2. Remove geocomplete search bar from the sidebar and move to the new popup modal.
3. Add fields to complete for listing entry
4. When user selects an address from the search bar, make the user verify it.
5. Create an ajax request/api endpoint for retrieving info from cookie.
6. When adding to database, the foreign key is the username, so get that from the session information.
7. #21

(PARENT TICKET):none

(DEPENDENT TICKETS):#21, #24, #30

(BRANCH): mercedes/accounts/32

(DESCRIPTION):When creating a new account it says "Account Update Success" after putting in your bits. We should know whether it's an update or a create and display the proper information. Also, When Logging Out it just kinda does it, we should be showing a confirmation message. Also, Deleting an Account also a confirmation. Lastly: the delete account button should be in the update account thing. We don't wanna make deleting easy. It should be not easy.

The footer needs to be fixed too, it is not spanning the sidebar. The logo should be padded less too so that the sidebar filters can more easily be put in without being squished.

(COMPLETION REQUIREMENTS):
1. Creating Account, fix popup
2. Updated Popups and logout notification.
3. Delete button moved (update-modal)
4. Footer span 100% of sidebar
5. Logo padded less in sidebar so there is more space below.

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH): mercedes/slider/70

(DESCRIPTION): We need to be able to query the listings no matter what price they are. At the moment, users can pretty much enter any rent amount. However, the slider on the front page is static to have a max at 3000. We need to find the max rent amount, and min (probably not necessary but could be useful) and then adjust the slider accordingly.

Mongo has functions for this that are very efficient - $max and $min

db.listings.aggregate(
   [
     {
       $group:
         {
           maxRent: { $max: "$Price" },
           minRent: { $min: "$Price"}
         }
     }
   ]
)

This will return values that would be inserted into the slider initializer.

$.ajax ... get values({
    success: function(res) {
        var data = JSON.parse(res);
        $("#PriceRangeSlider").slider(
        {
           range: true,
           min: data.minRent,
           max: data.maxRent,
           step: 100,
           values: [ data.minRent / 2, Math.max(data.minRent / 2, data.minRent / 2 + 300) ],
           slide: function( event, ui )
           {
              $("#amount").text ("$" + ui.values[ 0 ] + " - $" + ui.values[ 1 ]);
          }
       }); 
   }
});

(ACCEPTANCE CRITERIA):

1. Slider dynamically adjusts to highest and lowest value of rents.

(PARENT TICKET): none

(DEPENDENT TICKETS):none

@Saurutobi Marcel, you are boss at organizing things like this. Can you create useful labels and the milestones. I could totally do it but I know you'd get things that I might miss in this department.

(BRANCH): part of #5

(DESCRIPTION):We need a cool logo for the sidebar of the website. We need a fullsized logo, say minimum 1000px wide, and a scaled Logo for the sidebar. Please email the fullsized logo in ".png" form to Alex or Marcel for us to upload. We will create the scaled version based on our dimensions for the sidebar.

(COMPLETION REQUIREMENTS):Completed logo in 2 forms: Fullsize and scaled to dimensions for the sidebar.

(PARENT TICKET): #5

(DEPENDENT TICKETS):none

(BRANCH): mercedes/images/64

(DESCRIPTION): I'd like a Fullsize Image slideshow and for the Thumbnails to load quickly.

Essentially all I do here is just ask for the .Thumbnail property of the return object and assign to my src attributes of the image tags. However, I am still loading them asynchronously because that simply more efficiently and scalable than not.

(ACCEPTANCE CRITERIA):

1. Wire up #62 into Mercedes
2. Ability to view a slideshow of full-sized(or close to that, filling the browser window) images for the listing.
3. Interlaced Thumbnails on Mapview which load very fast, and Thumbnails everywhere except full-sized images.

(PARENT TICKET): none

(DEPENDENT TICKETS):none

(BRANCH): mercedes/list-view/16 merged into bmw/28

(DESCRIPTION): Create a popup slideout List view similar to the Log In popup. In this box, any found listings will appear and can be sorted by any property in ascending or descending order. They will be shown in minimized form with thumbnail images, and can be expanded for more information/detailed description by clicking on them. The sidebar should still be available for filtering.

Include the popups for markers into this because they will use the same code as the list view.

(COMPLETION REQUIREMENTS):Complete display of listings and expanding for detailed view.
#24 #26 #27

1. Address shows both address 1 and address 2 (if available).
2. #listings div is completely opaque
3. On window resize, the listing-view follows
4. #47 I want to do it here since it relates to how I build the list-view.
5. Users can only touch their own listings and account. No hacks!

To create the popups for the multi-listings. I am going to create a hash object that consists of the address as the key, and an array of strings where the strings are html sections that I simply insert into the modal template by iterating over the array. The hash objects are created on page load.

(PARENT TICKET): #5

(DEPENDENT TICKETS):#24 #26 #27 #55

(BRANCH):hummer/listings/54

(DESCRIPTION): Currently what happens is the the user is able to update the rent cost and the date in the listings view. However, it does update the editable section, of course, but it doesn't do realtime updating of the header bars in the accordion structure on the page. This would be better UX, instead of having to refresh to see it updated since that data is normally filled in by an ajax call.

(COMPLETION REQUIREMENTS):

1. Date and Rent updated in respective header on successful update.

(PARENT TICKET):none

(DEPENDENT TICKETS): none

(BRANCH): n/a

(DESCRIPTION): Create a bunch of listings to use as data.

(ACCEPTANCE CRITERIA):

1. Tenant listings
2. Landlord listings
3. Multi building listings
4. Single instance listings (doesn't have other listings at same location)
5. Good pictures.

(PARENT TICKET): none

(DEPENDENT TICKETS):none

(BRANCH):maybach/6

(DESCRIPTION):Create Ruby API for payments. JS/backend needs to be in place, as well as a simple hidden html webpage so we can test it working.

(COMPLETION REQUIREMENTS): Ruby API complete. Payments processing and returning results. Basic HTML page with simple buttons or something to test and sample each function.

1. Ability to login with PayPal and complete payment

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH):porsche/mockups/43

(DESCRIPTION): I want to talk about the future of the landing page. We talked about the landing page once, but never did again, and I think we should talk about them again. I'll add mockups so we have something for when we move onto this project.

(COMPLETION REQUIREMENTS):(things here, put it in a list if more than one)

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH): enhabit/regression/56

(DESCRIPTION): I need to do regression testing at this point to make sure that all functionality works because there are a ton of cross over changes that affect other branches and their functionality. It is far too difficult to make one change that affects another branch, but have to make sure that the other branch adapts when it actually breaks in its own current branch from the adaptation itself. This ticket is going to be a catch all for a bit, and then I'll move onto other tickets. Fix are made as needed.

(COMPLETION REQUIREMENTS):

1. Frontpage Login/Logout
2. Frontpage Login Facebook/Logout
3. Frontpage Create User - Normal/Facebook - Login/Logout with new user
4. Login with Tenant on frontpage - Enter tenant portal
5. Create listing in tenant portal
6. Edit, Update, View, Delete listing in tenant portal. Only one listing is allowed.
7. Validation errors appear for listing.
8. Edit, Update, View, Delete account from tenant portal. Changing username does not change the listing that the user has.
9. Create a single listing that is attached to a landlord that we can login with
10. Logout with Tenant - Leads to tenant portal login page
11. Login with Landlord on frontpage - Enter landlord portal
12. View listing created by tenant attached to the landlord
13. Create multiple other listings. - Make some with same address, different unit
14. Edit, Update, View, Delete listings from landlord portal.
15. Edit, Update, View, Delete account from landlord portal.
16. Logout with Landlord - leads to landlord portal login page
17. Listings appear on front page
18. Same-address listings appear with different pin
19. List view shows all listings that are currently on screen
20. Show All button on same-address listings brings up popup with all those listings at that location
21. View listings in List View or Show All, or single View shows a single popup with that listing details.
22. Query different listings with sidebar.
23. Create two users, attempt to hack the other user's listing either by updating the other's listing or deleting the other's listing. Solely the ability to view and do nothing else with the other's listing is not considered a hack. Attempt to hack the other's account, update or delete it. Solely the ability to view and do nothing else with the other's account is not considered a hack.
24. Frontpage zooms correctly on all the markers.
25. Test full functionality

(PARENT TICKETS): none

(DEPENDENT TICKETS): #16 #28 #55

(BRANCH): bmw/analytics/33

(DESCRIPTION): It would be helpful to have the google analytics viewable on the main page of the admin portal. The Google Analytics API would allow for the access of that information.

(COMPLETION REQUIREMENTS):
1. Google Analytics added to main page for now.

(PARENT TICKET): #28

(DEPENDENT TICKETS):none

(BRANCH): ferrari/images/62

(DESCRIPTION):I'd like a Fullsize Image slideshow and for the Thumbnails to load quickly.

What you Need to Get Started:

1. Install RMagick (go through Bluehost to do it)
2. Include the following code to the require list at the top of create_listing.rb and update_listing.rb
   require 'rmagick'
3. There is a complicated loop inside of both of those files that check for updates to the pictures array, and decides accordingly what to do about new files, missing files, or no files. You need to integrate with this loop to create/delete your thumbnails with rmagick.
4. You don't need a thumbnail parameter in the functions themselves, but you do need to insert them into the queryObj. Please insert them the same way as the Pictures array.

(ACCEPTANCE CRITERIA):

1. When images save, they are saved as Interlaced.
2. Create a second Thumbnail-sized image(200x300) that is also interlaced.
3. Save images in a Special Directory Tree: server/imagesaveddir/ListingID/ImageNumber/Thumbnail.jpg or Full.jpg

(PARENT TICKET): none

(DEPENDENT TICKETS):none

(BRANCH): (TBD)

(DESCRIPTION): We need basic CRUD Operations, and so far we have Create, Read, and Update.

Create: #8 (Completed)
Read: #15 (Completed)
Update: #15 (Completed)
Delete: (Do not have)

(COMPLETION REQUIREMENTS):
1. Ability to perform at least CUD of the CRUD operations, Read is completed in another ticket.
2. Updates in the UI as well as the Database with the particular command

(PARENT TICKET): #32

(DEPENDENT TICKETS): none

(BRANCH):bmw/mockups/29

(DESCRIPTION):We need to look at how each user, renter and leaser, will use our website. We should have two separate login sites. One for renters, and one for leasers which will take them to their Hummer. A leaser can act as a renter and view listings on Mercedes and such, but a renter cannot get to Hummer unless we(admins) activate them as a leaser. In addition, renters should not have access to creating a listing. This should only be able to be done through Hummer, and not through the main page. We also need to look at creating users. I think it's good that anybody can create an account, but I think on Mercedes in the footer we should have a button for "List Apartments": which takes you to a page where you type in some info and it notifies us(the admins) to vet the person and activate them. Similarly, there should be another button on the main login page which does a similar thing. We need to draw a clear line between Renters and Leasers, and make sure they're directed to Mercedes or Hummer correctly. Keep in mind, Hummer is a totally separate page without maps and stuff that we have yet to design(part of this invesigation).

(COMPLETION REQUIREMENTS):Talk the workflow over with the full team and discuss.

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH): bmw/28

(DESCRIPTION):
We need to figure out what we want to do with listings that are in the same location. The same apartment complex could have more than one listing but on the map they'd all be reflected by the same latitude and longitude. The user would only be able to select the topmost pin, and thus missing all the other ones.

Possible Idea:

1. Aggregate all listings that have the same latitude and longitude into the same pin somehow. Then when the pin is clicked it just shows multiple popups. Not sure how scalable that is, might want to turn into some sort of scrollable thing.

(COMPLETION REQUIREMENTS):
1. User is able to distinguish multiple listings from a single location.
2. User is able to select the listing they meant and not have another pop up.

(PARENT TICKET): #16 #28

(DEPENDENT TICKETS): none

(BRANCH):bmw/tracking/50 (To be Created)

(DESCRIPTION):We need a way for Admins to track use. Use
https://developers.google.com/analytics/devguides/collection/gajs/eventTrackerGuide

(COMPLETION REQUIREMENTS):
3. Create a page in the Admin site to display the tracking data.
4. Across the website, when a user does anything(like click on a button), we Track it

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH): hummer/create-listing/14

(DESCRIPTION): Current when you login it says "Account Creation Success" instead of just logging in.

(COMPLETION REQUIREMENTS): Login goes directly to main page instead of modal-3

(PARENT TICKET): #14
(DEPENDENT TICKETS): none

(BRANCH):(branch name here)

(DESCRIPTION):Listings View and the Detailed Listings aren't pretty or intuitive. Also, Mapview listings images load really slowly.

(ACCEPTANCE CRITERIA):

1. Listings View Cleaned Up
2. Detailed Listing Cleaned Up
3. Ability to view a slideshow of full-sized(or close to that, filling the browser window) images for the listing.
4. Interlaced Thumbnails on Mapview which load very fast, and Thumbnails everywhere except full-sized images.

(PARENT TICKET):none

(DEPENDENT TICKETS):none

(BRANCH):mercedes/designfixes/51

(DESCRIPTION):We've got a bunch of updates to the UI.

(ACCEPTANCE CRITERIA):
1.Remove the Site Tagline("Find Your Perfect Home Away From Home")
2.Center Map closer to NU campus.
3.Menus, Fields, Sliders should be light grey instead of white
4.Menus, Fields, Sliders should have sharp corners, not rounded ones
5.The Start Date field should only be large enough to display the date, it's too big.
6.The Date Field should have a "MM/dd/YY" as opposed to being empty
7.Price range should be the same violet as the logo. "0xb55783" instead of yellow
8.Price range slider buttons should be plain grey instead of glossy square
9.Button should be square instead of rounded
10.All buttons including "Log In" and "View Listings as List" should be consistent in size and shape.
11.Search button should be bigger than the others
12.View Listings as List changed to View Listings
13.Button colors changed to: primary: "0x5259e3", hover-over: "0xb55783"<-This might need a small fix with the search/expand options buttons. hover-over color being a little too dark. couldn't find the css for it. But I made them sweet rainbows!
14.Remove part of List View overlay to the right of the scrollbar
15.Put a clearly visible light-grey X in the top right corner to close the list view
16.Add a thin grey border around the listing window popup.
17.Remove shadows from font in Listing Window popup.
18.Remove United States from Address in Listing Window popup.
19.Featured Listings will get Gold
20.Responsiveness of all UI popup modules need to be tightened down.
View List Innerds
21. “View Details” doesn’t make sense instead of “List View” or "Show List View"
22. Move “More Details” to the right of the information, instead of below
23. Add thin, subtle gray line between items in list
24. Unrelated: Add an “X” to close the extra filters pop up

(PARENT TICKET):none

(DEPENDENT TICKETS):none