Activity
Posted in Bulk Operations in Rails Discussion
For those of you who want to use fetch instead of Rails.ajax:
let token = document.querySelector('meta[name="csrf-token"]').content;
fetch(/your/path, {
method: "DELETE",
headers: {
"X-CSRF-Token": token,
},
body: data,
}).then((response) => {
if (response.redirected) {
window.location.href = response.url;
}
});
Thanks for this gem!
Yeah, you can process the payment like any normal background job. Don't allow retry if the job fails (for fear of multiple payments), and return and update some sort of charge id on success to your database.
You really don't need to poll for the payment and respond to the customer that it was a success. I think most customers realize that when you input your card information, there's going to be a charge that happens at some point, and most don't really care for a confirmation that the charge went through (within your interface). This means you can just capture the card token and process the charge in the background, if successful update your Payment model (if keeping invoice data) that payment went through. If it fails, prompt the customer with an email to update card details and try the charge again.
In one implementation we charge customers on a nightly job based on a pre-defined schedule. Stripe never struggles with us throwing requests at it like crazy at midnight.
You're on the right track with moving the processing of the charge to a background job. I guess you need to answer whether or not the confirmation is important to your on-boarding flow.
Posted in Where to get started?
Recently I can put this on rotation and get to work: https://open.spotify.com/user/akahendy/playlist/0C7xiAjvGXJg0bc8umC6JA
I think the routes are confusing the system.
I'd do a namespace for your users.
namespace :users do
resources :jobs
end
And you can keep your original jobs path for external users.
Product and Category need to have many locations probably using a through association.
Posted in Just want to say thanks!
Too cool! Congratulations on the product release!
A subscription to GoRails is invaluable. The videos Chris puts out are great, the community is where it's at.
Posted in Best way to build a Contact Us page
As a bonus, I highly suggest you implement a captcha. There is a gem for googles recaptcha which is easy to install. Spammers will send you junk. They still get through recaptcha but less often.
Posted in ActiveRecord
Alright further testing:
=> #
irb(main):002:0> u.email = "test1@gmail.com"
=> "test1@gmail.com"
irb(main):003:0> u.save
(0.2ms) begin transaction
SQL (0.7ms) UPDATE "users" SET "email" = ?, "updated_at" = ? WHERE "users"."id" = ? [["email", "test1@gmail.com"], ["updated_at", 2017-02-08 19:21:31 UTC], ["id", 1]]
!--["test@gmail.com", "test1@gmail.com"]--!
(26.7ms) commit transaction
=> true
irb(main):004:0> u.email = "test2@gmail.com"
=> "test2@gmail.com"
irb(main):005:0> u.save
(0.2ms) begin transaction
SQL (0.5ms) UPDATE "users" SET "email" = ?, "updated_at" = ? WHERE "users"."id" = ? [["email", "test2@gmail.com"], ["updated_at", 2017-02-08 19:22:14 UTC], ["id", 1]]
!--["test1@gmail.com", "test2@gmail.com"]--!
(30.9ms) commit transaction
=> true
!-- output --! designates the after_update callback outputting the change value.
class User < ApplicationRecord
ActiveModel::Dirty
after_update :what_changes?
def what_changes?
puts changes[:email].inspect
end
end
Posted in ActiveRecord
Hi Sarah,
I felt I should help since I was helping you last week on Slack.
I went ahead and did some testing with ActiveModel::Dirty for your scenario.
Here's some output from rails console:
irb(main):009:0> u.email = "test1@gmail.com"
=> "test1@gmail.com"
irb(main):013:0> u.save
irb(main):015:0> u.email_previously_changed?
=> true
irb(main):016:0> u.email_previous_change
=> ["test@gmail.com", "test1@gmail.com"]
irb(main):017:0> u.email = "test3@gmail.com"
=> "test3@gmail.com"
irb(main):018:0> u.save
irb(main):019:0> u.email_previous_change
=> ["test1@gmail.com", "test3@gmail.com"]
Each time the object is saved the ActiveModel::Dirty will track the changes and return the proper updated "new" old email. I think it's still working as you need it. The first email in the array is always the old email that you want to send the confirmation to.
No problem, and, yes the output of the code in Chrome inspector.
You can just post the parent select and one of the option tags. I just need to see what it's outputting to get you on the right track with the JS.
Post the select element that the server outputs here. We can get this working. :)
Oh, easy!
This should get you the data attribute value:
$('select#location_id').data('modifier');
You'll want to look into the jQuery .change method too to watch for changes on the select tag.
Hello,
Output your modifier value to a hidden text field and grab it with jQuery and do the logic to display the form field or hide it. You can just include a normal JS file rather than learn CoffeeScript (I personally prefer normal JS). Simply rename the file to .js.
+1 for Vue.js
Hi Rob,
I noticed that while looking at your code the first time. I knew there may be another issue with the favorites_for method.
What I like to do when debugging is open up rails console and find a user with and without any favorites (or whatever object you're working with). Then simply try to run user.favorites.where(post_id: post.id).first and see what it returns. You may very well be having a user that doesn't have any post favorites and you aren't accounting for that in the view.
Alternatively, I think line 1 in _favorite.html.erb may be the culprit of the error.
The if should be checking for not nil (appears you're setting a variable). Put the current_user.favorite_for(post) down where you have the variable. Then it should hit your else for the other case.