Yeah, should be able to set it up without Users. That's what guests are anyways, they don't have a User. You can always ask on the GitHub issues for it and get tips from the author. 👍
So what I would probably do here is actually:
resources :milestone do member do post :activate, to: "milestones/activations#create" delete :deactivate, to: "milestones/activations#destroy" end end
Then you can have a
app/controllers/milestones/activations_controller.rb that handles them. That's great for separating out the logic from the main CRUD, and your routes aren't too complicated.
I'll often make a singular resource for things like this too.
resources :milestone do scope module: :milestones do resource :activate end end
Works a bit better if you're doing like
resource :advanced_search or something.
In your case,
DELETE /milestones/1/activate doesn't make sense, and you'd want the destroy route to be
DELETE /milestones/1/deactivate so it's more intuitive. And that's why I'd probably write the custom routes instead of resources in this case.
I think it's fine for you to make some non-standard actions here.
Are these actions changing the Milestone record or are they change an Activation / Completion records associated to a Milestone?
Helpy is great! Deployed it via Hatchbox a little while back and it keeps improving.
I think you can probably use the API to create users after they're created in the main app. https://support.helpy.io/api/#operation/postApiV1Users
If they both use Devise, you can sync the user accounts between the two databases and then set the cookies to store on
*.domain.com so they're automatically logged into both. The apps would need to share a secret key base for that since it would be decrypting the same cookie.
That's the ideal so you don't have to have the users go through any process.
You can do omniauth and make your main app where the user logs in the provider and then every other app can be the client. That will work too. You might be able to tweak it so they don't have to approve and it automatically approves the OAuth request so it is more seamless.
Yeah, it'd be a great way to test and make sure your Vue app was integrated correctly with the Rails app. You can also look into things like Jest to test just the JS independently, without Rails.
You'll need to use their API to do that. Check out this gem: https://github.com/eddiezane/sendgrid-actionmailer
Shouldn't be too bad. You'd want to figure out what it means to abandon the cart. Is that a cart that was last created 1 hour ago that wasn't checked out?
Then you'd want a cron job to look for those carts every X minutes or so, and then send the email. You'll probably want to mark those carts as "abandonment email sent" or something so you know to filter them out next time.
The cron job running every X minutes should always find ones created one hour ago and incomplete, so that the emails get sent out regularly.
Posted in docker screencast?
Probably at some point. I don't have any specific plans for it yet.
Yep, check out the JWT from scratch episode instead. That one will work just fine and you won't have to depend on other maintainers.
You should be able to use mixins in the asset pipeline, as long as your filename ends in .scss so it gets processed with scss.
It won't hurt to use Webpacker for everything. In fact, you need to in some cases like when you're using TailwindCSS.
Images don't really need to go through it since they don't need to be preprocessed and if you have simpler CSS, then the asset pipeline is still around for that.
@Ivan, no, not during deploy. You should already have done that so they're added to your package.json. The assets:precompile step will make sure they're installed during deploy.
Heroku does need you to add the node buildpack alongside the ruby buildpack so you can use yarn.
heroku buildpacks:add heroku/nodejs heroku buildpacks:add heroku/ruby
That's actually using the data-confirm-modal gem to use Bootstrap instead. It's kind of hacky how it replaces the confirm method in Rails JS, but you can check out the source here. https://github.com/ifad/data-confirm-modal
iTerm is so dope, thanks for sharing that! 🙏
Yeah, one of the reasons I choose to use Minitest over Rspec is that it's mostly just pure Ruby. You have a couple wrappers around
assert, but it's really just Ruby code. Less magic means it's more reliable to reason about.
Headless browsers I do believe can still generate screenshots. I will try it to make sure. The main reason you need a headless browser is on your server, you don't have a screen, so there's no windows to actually render. It's all virtual.
Posted in Rails 6 + ActiveAdmin + ActionText
Administrate has a plugin or two for ActionText if you are adding an admin.
And probably the best long-term approach would be to just build it yourself that way you have full control over how the CMS works and aren't fighting with an admin gem. That said, it's a lot more work so may be something to do later on.
Create new ones like
has_many :old_associations, foreign_key: :old_id or whatever options are necessary.
You can specify the column on your association that's used for joining tables. You'd just specify that
old_id column and you should be good to go.
Posted in Multitenancy with Apartment Gem
@Vitor the Apartment docs should have a good explanation for that. 👍
I would use a Stimulus controller to listen for "change" event on the radios and then update the hidden fields accordingly.