Ahhhhh! It's ALIVE!

I finally deployed my listing manager app to Heroku.  For the longest time it's been sitting on local host, simply because it needed API calls to provide the content to fill the views and the API keys needed were my own.  StubHub's sandbox hasn't been working for longest time and they haven't been responsive to this issue.  So to get around this, I set up a demo account with limited permissions, basically, you can GET from the API, but cannot PUT/POST/DELETE.  The downside is it's still limited to 10 API calls per minute, which is why I'm not going to post the demo account credentials on here.  But if you'd like to take a look, get at me and I'll send you the login credentials.

New Features Added

User Permissions

As I eluded to in the intro, accounts now have permissions.  This was originally done so that I could have a demo account, but I quickly realized having a permissions table belonging to users would be helpful for managing master > sub accounts since many ticket resellers have employees who also need access to certain things (such as updating prices or creating/deleting listings) and not others (such as profit and loss, or account preferences).  I didn't do any research on the correct way to implement permissions, so my design might not be up to snuff with convention.

In short, Account has_one Permission and Permission belongs_to Account.  In the controllers, some methods have before statement that checks current_user.permission for the correct permissions.  If the user is not permitted, he/she is redirected_to the current page with a flash[:notice] letting the user know they do not have permissions to access that method.

User Settings

Some of the features in the app are susceptible to a users' unique preferences.  For instance, events change color depending on how far out the event is.  Some events, such as concerts might start peaking in sales immediately after an on-sale as well as a few weeks prior to the event, so having an event turn red three days out wouldn't be of much use.  Conversely, soccer tends to be pretty dead until one to three days from the event date.  With User Settings, each user (whether master or sub account) can set their own preferences for when events turn red/yellow/green/blue.  In addition to event date coloring, users can select how many days Recent Sales covers.  This is useful because a large brokerage may only want to see the last 24 hours, while a small brokerage finds it more useful to see the last seven to 14 days worth of sales.  And finally, users can set the chart types that show on previous event reports.

Report Charts

While this area is very much in its infancy, I though it would be useful have to charts detailing different sales metrics.  The first (and currently only) metric that has been implemented is sales trajectory.  When viewing a past event, users can see how many sales a specific event had for each month from the first sale to the event date.  The charts were made using the Chart.js framework and were really simple to integrate with Ruby.  The only 'gotcha' I came across was while injecting Ruby in the JavaScript.  Using ERB tags and passing in only the variable doesn't work, the data comes through without the proper quotes around each string.  Here was the issue and the solution:

Problem
<%= @chart_labels %>  => [&quot;January&quot;, &quot;February&quot; ...]

Solution
<%= raw @chart_labels %> => ["January", "February", ...]

More charts are coming in the near future... ideas? :)

There were a host of other small things added, like CSS styling, locking out User CRUD, and finally the process of deploying to Heroku, but all that's less interesting, so I'll omit that for now.

The app can be viewed at https://listingsplus-staging.herokuapp.com 

If you'd like to poke around, let me know and I'll give you the creds.

Form_For: Gotcha!

Hey!  Why is it that my form won't post unless I refresh the page?  The submit button simply doesn't respond to clicks. :(  Surprisingly, the answer was simple and it appears that it's not a Ruby on Rails issue, it's actually an HTML issue when using form_for.

If you're running into this issue, it would be my guess that your form is nested inside <table> tags.  That was my issue.  It seems that if you're going to put your form in a table, you *must* wrap the <table> tags with the <%= form_for @user do |f| %> ... <% end %> erb tags.

Here's a before and after of my issue (broken code and fixed code):

BROKEN CODE - Notice the form_for erb tags are nested inside the HTML table tags.

FIXED CODE - Just moved the form_form erb tags outside the HTML table tags.

If you know why this works, I'd love to hear your explanation.