Chris Oliver

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.

You might be able to add an association to the task like has_one :project, through: :domain to remove the domain out of it, but it's not going to make much difference. Shortening this only really moves this code somewhere else.

I'm not entirely sure I'm following. What's the domain object for? And the problem you're having is trouble rendering the task's project name? Does something like <%= @task.domain.project.name %> work?

How are you associating the tasks to the project and what code do you use to switch them between projects?

In this case, the information is just saved to the database so you could do what you want with it.

So we use public_activity to track the views and completions of each step. You can complete a step a few times, so to calculate the progress, you count the number of unique steps completed by the user and the total number of published steps in the course and divide those. That's really all there is to it! The public_activity gem makes creating the activity records pretty easy so than all you'll have to do is grab a count after that.

The Facade Pattern is a pretty simple one. In Rails the guideline is usually to only have like one instance variable that your controller sets. Reality is that often times you need several variables to render the page, so they create a little Ruby object that's nothing special like their example of Dashboard. It just has a few methods so you interact with the Dashboard instead of several different instance variables in the view.

This pattern doesn't really improve your code all that much. It more hides the complexity behind a facade (hence the name) but it significantly improves the controller code.

You can simply create an app/facades folder for this and as long as the directory loads (you may need to add it to the Rails config, can't remember), then all you'll have to do is create some basic Ruby classes that load the correct records and you're all set.

You beat me to it! Pundit's exactly the right thing for this.

Maybe, maybe not. It's definitely new but it's not much more than some basic scaffold generators right now. Nothing too special. I wouldn't use it on a client project yet, but I'd absolutely use it on personal projects.