Chris Oliver

Woah, that sounds scary. I've never seen that before. Is it deleting records or something else?

For nested queries like that, I think you can use benefits.id as the field. This might be of some help: http://www.elastic.co/guide/en/elasticsearch/reference/1.4/mapping-nested-type.html

I think I'm following you. The before_create seems like the right place to do this for now. If you're doing this before the record is created, you'll need to reference the in-memory objects through the association.

You might have a simpler time by moving this into the ItemDetail rather than the DetailAction. You'll need some way to match the two DetailActions together based upon the part (like "electric water heater") and then you'll need to separate those two items by the action ("replace" or "maintenance")

Once you have those two DetailActions together, you can first start with the replacement sequence, generate it, and then generate the maintenance one minus the replacement schedule.

If you've got the fields for the part and the action, then you can group these based upon the part field with Ruby's group method. Then you'll just go through each group, find the replacement DetailAction, calculate the replacement sequence first, save it, and then do the same thing for the maintenance.

Does that help at all?

Since you're going to need to do different views (it seems) for the forms on each plot, you may need to create a generic controller and view that can dynamically render the form based upon which report is selected.

If you choose "scatter_plot" in the form, then the next page could render a scatter_plot.html.erb view. And you could also use this param to call a report class.

After submitting, probably having some plain ruby classes that do the logic of taking the data and producing the graph. Setting up a common API on a set of "Report" ruby classes could help a lot here. They could all have an initialize method that accepts the data from the form and parses it as necessary. You can add a render method to each class and then use that for rendering out to the view.

If you have a variable with the name of the graph, you can do graph_name.constantize to grab the Ruby constant for the class. It would help you take something like "scatter_plot" and convert it to ScatterPlot and your code can create a new instance of that class dynamically, pass in the data, and render it out. Obviously, since your reports are all going to be somewhat different, you'll need to create a good amount of these classes, but you can start extracting their shared features to a Report class they could inherit from.

ElasticSearch definitely lost a good gem with Tire. It really seems like the new ElasticSearch-rails gem isn't anywhere near as friendly. There were a few other good ones that I can't seem to find.

From my reasonably limited understanding of search, you'll want to index Products and include the benefits inside of the Product record. That way when you do a search, the match on Benefit will return the Product.

Not sure if that helps you at all, but maybe it's a start?

I would think that you could loop through all the existing records you have and try doing Apartment::Tenant.create('tenant_name') on them, replacing tenant_name with the subdomain obviously.

It does sound like the teachers aren't sequestered appropriately yet. I don't quite know how to move records between the global tenant and a specific one, but that is probably what you need to do so they are stored separately.

Curious what you come up with to solve these problems. Keep me posted!

You're always calling PostPolicy.new but Pundit provides a helper that creates the new policy and sends in those objects.

Since we inherited from ApplicationPolicy, the initialize method there is the one that sets the user and record variables. We created that, not Pundit so you have full control there.

When you call "authorize @post" it looks at the @post.class which is Post. Then it makes that a string, adds "Policy" on the end and looks up that class which would be "PostPolicy". That's how it knows to grab the right policy.

Definitely plan on doing more Javascript / CoffeeScript soon.

That's a great idea. I'll add it to my list!

Yep! All your classes are available inside your POROs like you would expect. The things you won't have access to are things like "params" that come from inheriting ApplicationController. You'll have to pass those in.

Yes!! I'm definitely planning on doing a "Rails-from-scratch" series so you can see exactly how all this comes together from just regular old Ruby. Really looking forward to it but need to get it all mapped out beforehand.

Are you able to go back and retroactively create those tenants for records that already exist?

Sounds like you've got issues with apt-get running. Other people have had the same issue it looks like so you'll want to make sure that you can run "sudo apt-get update" successfully it seems.

http://stackoverflow.com/qu...

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.