Create hidden Administrator site

[ghost]

(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

[Harmonickey]

1. Most of these functions are completed already, just need to finish up the CRUD tickets.
2. Same as 2.
   Those two steps just need a form of some sort on the admin page.
3. This requires a separate table/collection, an archive of payments information that you want. I wonder how the payments stuff works in terms of storing the credit card information. It would be much nicer if they just required us to supply an OAuth2 connection and then gave us the information in the backend, which would take care of it. I'm not sure if that's a thing though, we may have to be super secure about it in the database (which is reasonable, considering all the cool security stuff mongo and ruby have to offer).

[Saurutobi]

no card info saved. ever. we will not hold that info at all

On Thu, Jun 25, 2015 at 10:37 PM, Alex Ayerdi notifications@github.com
wrote:

1. Most of these functions are completed already, just need to finish
   up the CRUD tickets.
2. Same as 2. Those two steps just need a form of some sort on the
   admin page.
3. This requires a separate table/collection, an archive of payments
   information that you want. I wonder how the payments stuff works in terms
   of storing the credit card information. It would be much nicer if they just
   required us to supply an OAuth2 connection and then gave us the information
   in the backend, which would take care of it. I'm not sure if that's a thing
   though, we may have to be super secure about it in the database (which is
   reasonable, considering all the cool security stuff mongo has to offer).

—
Reply to this email directly or view it on GitHub
#28 (comment).

[Harmonickey]

good, that would suck. I'm sure the APIs have a good method of doing it.

[Harmonickey]

Would we be okay using this wrapper for the admin portal? It fits nicely with the Twilli theme and it's very manageable. http://jumpstartuidemo.com/themes/base/index.html It's $10

[Saurutobi]

Is it free? Otherwise we don't really need anything crazy. I was gonna go for a really basic page

On Jul 2, 2015, at 17:38, Alex Ayerdi notifications@github.com wrote:

Would we be okay using this wrapper for the admin portal? It fits nicely with the Twilli theme and it's very manageable. http://jumpstartuidemo.com/themes/base/index.html

—
Reply to this email directly or view it on GitHub.

[Harmonickey]

$10, or I could just custom make it

[Saurutobi]

$10 isn't very much... I'll let you decide. The admin page is our backend so what we like is what we'll take.

[Harmonickey]

Yeah, having the pre-wrapper stuff though will save a ton of hours, and it's easily customizable. We get it forever too, we can reuse it as much as we want.

[Harmonickey]

How do we want initial security to work here? Admin user login to main site page (Mercedes page) and then they click a button that redirects them? The session would be set in Mercedes and passed along to Bmw. If the user logs in and is not an admin, a message appears saying that they cannot proceed (but the button wouldn't show for them anyway, but just in case).

Or....
The admin user logs into the admin portal itself, a splash page appears that only includes a login modal. Again, they would be authenticated and either put through or told that they cannot proceed. There would be no indication that there is an admin page from looking at Mercedes, or the page source.

[Saurutobi]

Option 2. BMW is independent of the main page.

On Sun, Jul 5, 2015 at 2:22 PM, Alex Ayerdi notifications@github.com
wrote:

How do we want initial security to work here? Admin user login to main
site page (Mercedes page) and then they click a button that redirects them?
The session would be set in Mercedes and passed along to Bmw. If the user
logs in and is not an admin, a message appears saying that they cannot
proceed (but the button wouldn't show for them anyway, but just in case).

Or....
The admin user logs into the admin portal itself, a splash page appears
that only includes a login modal. Again, they would be authenticated and
either put through or told that they cannot proceed. There would be no
indication that there is an admin page from looking at Mercedes, or the
page source.

—
Reply to this email directly or view it on GitHub
#28 (comment).

[Harmonickey]

okay, already on it

[Harmonickey]

For the data reporting from google analytics, I will need to know what data we care about from this list

https://developers.google.com/analytics/devguides/reporting/core/dimsmets
If you need to login, check Logins.xlsx in Dropbox for the LbKStudios Gmail login.

For now, I am getting...
ga:users
ga:newUsers
ga:sessions
ga:avgTimeOnPage

ga:sessions
ga:percentNewSessions
ga:newUsers
ga:avgSessionDuration
ga:avgPageDownloadTime

[Harmonickey]

Sick... the google analytics works well.

[Saurutobi]

so I created the template site and checked it in. I'll hit it tomorrow with updates and such. AWS is made too, i'll put the rdp thing in our dropbox

[Harmonickey]

finished with listings and users admin pages for the admin portal, also finished with admin session logging in, your user needs to have the flag IsAdmin which can only be set through shell or through the admin portal itself. The only thing left is the payments admin section, and testing all the functionality one last time. However, before I go to payments I will finish up the front page because now the listing functionality is pretty much all there. I have every behavior command written and tested.

[Harmonickey]

Note that none of the requirements here actually work, I need to refine them to work with the current api and functions we have implemented from our other tickets that have been making things more efficient.

[Saurutobi]

please explain. Requirements for the ticket should not change based on what the system can and can't do. They system should change to be able to do what the requirements are asking.

[Harmonickey]

I meant what I wrote, I crossed off things above indicating that they work, but they don't right now. I need to fix them. I am being lazy and not uncrossing them, which is what I should do instead of writing a silly comment. :)

[Harmonickey]

I have pretty much everything written for admin, just need the changes made from list-view since there are refactoring changes in the Core as well as listings and account structural changes that will make it easier to test admin later. Blocked until it gets pushed through to master.

[ghost]

wait so what needs to happen with this ticket? Is it Ready for Release? is something else blocked because of this ticket?

[Harmonickey]

admin can now not enter tenant or landlord portals. user tab has been finished up, will proceed with extensive testing. listing tab is fairly completed, haven't looked at it much yet. need to include queries to get all users and all landlords so create-popup has autofill textbox of those fields.