Chris Oliver

Yes that does look correct. Remember that this only fires at real period end, not when they cancel.

Are you sending over some test events for it that aren't finding the user?

Maybe Javascript libraries like http://fullcalendar.io/ but no gems that I'm aware of.

Ah hmm, I can't remember, did that episode include adding a user_id column and belongs_to :user association to the comments? I thought it did but it's been a while. :)

If you don't have that, you'll need to do that to reference the user and that should do the trick.

So right now there's no way to do that with simple_calendar. It's a somewhat complicated thing to do to reproduce Google Calendar style multi-day events.

One option you have is to add some code to the view to look for events that started before the current and end on or after it to find multi-day events. You can create a helper to do that or add some code to your controller.

At some point I'll be patching that in simple_calendar to help make it easier.

You can do exactly what you've got here with the association on the comments. What's not working?

Nothing really. It's pretty straightforward. You just want to use remote: true on the form and add the JS response to the action like you normally would. That's about it!

I don't think there are any changes between the gem in development and production. You should be safe there.

I would do something like this (using the group_by_month method from groupdate so it's a bit cleaner).

@tasks    = Task.all.group_by_month(:date, format: "%b %Y").count
@finished = Task.finish.group_by_month(:date, format: "%b %Y").count
@unfinish = Task.unfinish.group_by_month(:date, format: "%b %Y").count

Ah yeah, your group_by is going to give you a hash. You probably want to do group_bys on those after filtering the queries to make it cleaner.

Yup! I would recommend doing scopes for this for sure.

You're welcome man! :)

You can make that a bit easier if you do select too:

@tasks      = Task.group_by { |t| t.start_date.strftime("%B/%Y")} 
@finished   = @task.select{ |task| task.status == 'Complete' }
@unfinished = @task.select{ |task| task.status == 'Cancel' }

I think you'll need to filter the array of tasks for each status, create variables for each of those, and then pass those in as different series to your chart.

Yep! It's all AJAX based and includes showing avatars and stuff if you wanted to show a few people's faces who liked the post as well.

I know they've been discussing it at least. That's the last feature I've been waiting for but I know it's coming soon so I've already started a few apps using Administrate knowing that.

I guess it depends. It is just basic scaffolds for your gems, so as long as you don't mind updating it regularly, I don't see that there's much to worry about with it.

Have you watched the AJAX episode? https://gorails.com/episodes/jquery-ujs-and-ajax

Hey Erick, did you get this figured out? I was doing a bit of traveling for the holidays and missed your post.

You may have to adjust the hashes for HighCharts, but the groupdate gem is pretty good for this. It was designed for the Chartkick gem. https://github.com/ankane/groupdate

Yo! Sorry I got behind on answering forum questions over the holiday weekend.

So I actually just do almost exactly that. The one thing is you probably won't want to actually remove the stripe_subscription_id just yet because they still have a subscription until the end of the period. It's good to keep it on the user until it's actually removed.

You can have a webhook that listens to the actual cancel subscription event in Stripe which will happen at that end_date. That webhook response can actually remove the stripe_subscription_id from the user effectively canceling their account. You can also remove the subscription_end_date so that doesn't display in their account section as well.

The Stripe Webhooks episode can help on setting up the webhook listener for this event. https://gorails.com/episodes/stripe-webhooks