Chris Oliver

I'm sure you could. You probably need to switch the tenants manually in this case. If you didn't need the company in the URL, you could also have it switch tenants in a before_action on every request based upon the user that is signed in and the tenant they are associated with.

This is definitely an important thing to decide upon. If you do this poorly, you could end up with a really complex set of reports that are a real pain to do maintenance on.

It sounds like you might be able to structure these reports to hit search and then your reports could simply cache a copy of what the query looks like and maybe you can build configurable views for them that you could simply configure in JSON or YAML somewhere.

Do you have an example of a few reports you might want? I'm trying to get an idea of how they might be alike or different and then extrapolate from there on ideas to whittle it down.

Cancan makes a good amount of assumptions that you are doing the normal Rails lookups here. There are a handful of different ways to make them work together, but the best one I've seen is to not use the load_resource and to authorize in the action instead: https://github.com/norman/f...

Awesome!

The only difference is to deploy your other apps to separate folders, create their dbs, and add another server config to nginx so it knows to serve it up on a different domain/subdomain.

Thanks! I appreciate that a lot! :)

Should it be locals: {pin: @pin} instead? I'm assuming you are just missing sending the pin from the controller.

For more database-related things, a transaction is good because it gives you the ability to do multiple changes to the data without them partially being finished.

With APIs it is a bit harder since you cannot roll back the execution of the API request. In this case, you basically want to log something immediately after the API request is finished denoting that this part of the job has been completed.

In the case of sending an email, you will need to make sure that your code after a successful send is very simple. Immediately after sending, you will want to write a record on the user that the email was sent. At this point, if the job died and was retried, you would be able to check if that email was sent and then cancel this job.

So creating the database and creating the tables are separate. The migrations are what tells the database which tables and columns to add and the database is just the one place to store everything. You'll want to make sure the migrations run on the server.

You should be able to do that with cap deploy:migrate

Well, the issue isn't that the packages aren't maintained properly. It's that the software doesn't get upgraded to be compatible with the latest Ruby releases always. Sometimes you have code that works on specific versions of Ruby and that means you will need to install that version specifically on your server. That's why everyone recommends using a Ruby version manager of some kind like rbenv to handle this. Once you get the hang of it, it goes smoothly, but at first it can be daunting and a bit of a pain to set up.

Hmm, not sure what's wrong exactly. Also you could just create the db after getting into the psql console by doing CREATE DATABASE your_database_name. Then you need to grant all privileges to that user on the new db.

Great reference for this stuff:
http://www.cyberciti.biz/faq/howto-add-postgresql-user-account/

Gareth - It is probably because your Postgres user doesn't have create database rights. You may want to either fix permissions on the user you are connecting with, or login as the postgres user and create the db manually.

I've been having a couple hiccups with the new version of Passenger and it's connection to the database. Going to revert back to Puma for a bit and that should solve the errors posting.

I think Cocoon technically calls these "nested forms" since you're dynamically adding new form fields for new objects.

Might need to correct me if I'm misunderstanding the issue here, but this is what I think is happening:
One thing that might be happening is that when the page re-renders your form actually renders using the @recipe and the assocations on it without using @contents variable. I think you probably have two options there. Either adding a scope into the association to order the contents or seeing if you can pass in @contents as the variable to use for rendering the fields.

Yeah, that's correct. It only runs in the browser on a page view. You'll get very basic data with it.

Segment is fantastic for us because it allows us to track custom events and not just page views. We can keep track of "User signed up", "User subscribed", "User canceled" and then have all this information to see where people are dropping off. It's a different set of analytics which is more valuable at certain times than others. Getting a basic Google Analytics implementation and then figuring out what's important to measure later on is usually what I do. Basics first, then add some complexity as needed later.

Looking good! Glad you got everything figured out.

Yeah, it's one of the methods generated by the has_one association. The docs show it as "build_association" and "create association". http://apidock.com/rails/Ac...

You could do that by scoping the comments further by adding ".where(user: current_user)" to the query in the controller.

Oh awesome, glad you got it working! :)

That would happen from missing the method: "POST" parameter in your $.ajax call. When a form is submitted via GET, it sends all the fields over in the URL instead of in the body.

If you make sure that it's sending a POST through, then you should be set.

Ah it looks like it's sending webhooks back. Those are always a bit tough to test in development because your dev server isn't publicly accessible on the internet.

Thanks for sharing GoRails! :)