Chris Oliver

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

Yeah, that's probably the easiest way then. This is one of the reasons I'm not a huge fan of ActiveAdmin because it can be fairly opinionated at times on things like this. Overall it's a great admin, but you might check out the recent episode on Administrate if you want to try an alternative.

You can open an issue on the ActiveAdmin github page to get some help from their maintainers. They're really helpful for this stuff.

I've never used Sorcery with ActiveAdmin so I wont' be of huge help here, but I imagine you can just copy that view into your app, override it, and adjust the links.

Did you get it working? I wasn't around for the holidays for a bit.

I believe you can eager load the comments through the association in the index query and then just use the association to render them out on the index page. Is that what you ended up doing?

Definitely not pointless as you'll still need to build a frontend but this will help you interface with Rails a bit easier.

I think the trick here is in your authenticate admin user method. You don't want to redirect if their an admin, only if they aren't (so you don't get a loop).

def authenticate_admin_user!
  if !current_user.admin?
   redirect_to new_user_session_path
  end
end

Yeah, I don't know of _any_ generators that have an uninstall. Git works perfect for removing them though.

Yeah that solution only really works well for whole numbers. One option would be to interact with meters, but actually store centimeters as whole numbers in the database for example.

Otherwise, you probably will want a separate model for recording each time things are taken. Then you could specify the "amount" on it, such as "6.5" so that instead of having separate records for each individual one, you'll have one record for the total amount taken at the time. You'd sum up the amount column to find out how many were taken rather than count the records like before.

I don't have time to at the moment, but might be able to next week.

Yeah, that gets pretty tricky. We had to do that at One Month and it became kind of a complicated piece of work. It was a nightly cron job that calculated the end of the month on the same schedule that Stripe would do monthly. We would look up users expiring and give them access to their next course. You also have to take into account things like extra days in months, leap years, etc. It's really not fun so if you can get by without offering the yearly plan for something like this, I'd probably recommend it.

You could also have a simple 30 day schedule for every yearly user that's a little different than the monthly users. People generally won't notice the difference and it's a lot simpler than making a perfect copy of what Stripe does yourself.