Chris Oliver

You're welcome! 🤓

Hmm, I wonder if you need to include the address ID in the form as a hidden field so Rails knows which records to update. If it doesn't have the ID of the nested model, it is just going to create a new one, so that might be what's happening here. It seems like it's creating new records instead of updating the old ones. Does that sound right?

Just pass in the user_id in the URL on the link, and then set it as a hidden field inside the form rather than a select tag. That should do the trick!

Maybe you didn't add a role string field to your model? That's usually the case when you run into that error.

Oh yeah :) I use Wistia to host them all. They upload them to S3 (or wherever they use) and probably serve the files up through a CDN. I let them handle it but if I were to do it myself I would use S3 and CloudFront probably.

It should just pick up the searchbox ENV variable and work. Depending on how many models you're indexing, you'll need the correct number of shards available (some of the ES options limit shards or other things).

@episodes is the instance variable you'd set in the controller just like you normally would when printing out the index.

Welcome! :)

The simplest way to go about this is probably to create just one User type but add a role attribute to it. Just make it a string to keep it simple. When you sign up, you can choose either Student or Teacher. Depending on hwich one you select, submit the string "student" or "teacher" for the role field so it can get saved to the database.

You can use that role attribute to redirect them easily. Then you can have to different types of profiles in your database. StudentProfile, and TeacherProfile. You can put any of the fields you want to have on those, and then ask them to fill out the correct type of profile after signing up based on their role.

Let me know how it works out!

Yep, you'd need to include that in the cache key so they are all separated out cleanly. Don't want to be leaking any of that information between schemas.

That is correct. Whoops!

Yeah, you can use anything you want to switch the tenant. I'd ask this question on the Github repo though. They're the ones that know it really in-depth and can get you the best answer!

Wow, sounds like terrible support from them, hopefully they improve with that. I hadn't heard of them actually. I'm using Mailjet right now, but their UI needs some work. Possibly going back to Sendgrid myself, but we'll see.

Normally you would just make HTTP requests to something like this if it has an API. It doesn't look like this has one, and it's probably not written in C because that's just too much work for building a website generally. This is probably mostly JS and some server side language like PHP, Ruby, or Python.

A couple reasons:

1. You only should see notifications where you are the recipient.
2. The actor doesn't matter, it's just some other person that took an action that you should be notified of. You don't really care about the actor, so you can pretty much ignore that relationship which means you don't need to define that second set of notifications. It's a relationship that could exist, but since you will probably never use it, we don't define it.
3. A little unrelated, but you'd also need to change the name of the second "has_many :notifications" because that would override the first one.

There are, although I haven't personally used any so I can't confirm if they're any good. You can check out like https://www.nitrous.io/ and https://c9.io/

I would rewrite those tests to use those classes directly. It'll clean up the tests and then you can optionally have the test for the Customer model that tests the integration of the two classes if you keep that.

My bad :) Should have given an example.

  link = $(event.target).data("url")

Replacing that line with the above code should do it. The event argument contains all the data about the event, including the link that was clicked. That's the target attribute. You can then just access that like the above and everything is nicely scoped.

Yeah, that makes sense given the scale of support they need to have. I bet the average user for them is connected to like 20 chat rooms in each organization, and then like most of my friends, connected as well to like 5+ organizations. That's a lot of DOM manipulation that you can postpone until later.

Right, and that would be because now that you changed scopes, the this variable references the JS object now instead of the element in the callback. Scopes in JS are quite tricky huh?

Solution now would be to use the event.target from the argument the callback receives. That'll be the link that was clicked, and you can then replace this with that in order to accomplish the same thing.

It probably makes the most sense to have those on the page by in hidden divs. That way you don't have to store all those messages in memory in a hash of some sort and you can inject them on the page as HTML. They won't be visible, but you can continually still get updates for them. Everything will continue updating in realtime, you're just visually hiding everything but the active channel.

My guess would be that Slack's app works the same way when you're logged into multiple channels.