Chris Oliver

Hmm, well if that didn't work, might be a bug in the gem. I'll spend some time on it today after I get a screencast published for this week.

Yep, it's a good and a bad problem at the same time. :P

In that case, I think you'll want to make sure that your calendar_events method is creating the right virtual events. Just do a single multi-day event and make sure that it generates 3 Event objects if it spans 3 days. The start and end times for those should be for their respective days. My guess is that there's something wrong in the generation of these and that's causing the discrepancy.

If you verify that works correctly, we can then eliminate a lot of things and figure out what else might be causing it. I'm going to make a simple example of multi-day events with simple_calendar as well to make sure those still work as expected. Nothing should have changed with them, but it'll be good for a double check.

Hey Alan,

Yeah sorry, super busy lately. It never gets easier. :P

One thing I just noticed is that you're not actually using the events that simple_calendar has parsed for you. When you pass in the events into the calender method in the view, it will yield to the block the day and the filtered events.

<%= week_calendar events: @events, attribute: :start_at, end_attribute: :end_at do |date, events| %>
<div><%= date %></div>
<div>Events:</div>
<div><%= events.inspect %></div>
<% end %>

Try something like this code to see what it outputs for the events. Note the new events parameter for the block.

For that, you'd probably want to build a Rake task to convert the existing data. For example, you'd want to probably use regex to parse out the existing strings into their parts and then reformat them with the new version. You don't want to run it through the new process exactly, so you'd end up writing some one-time-use code for this which makes the most sense to do in Rake or something similar.

You can just paste the relevant snippets here. I'd be interested in seeing the model's columns aside from that piece. Something's not wiring up correctly most likely but there could also be a bug in the gem.

Sup Alan,

Can you share the code you've got for this?

And did you follow the end_attribute stuff here? https://github.com/excid3/simple_calendar#rendering-events

That looks pretty much like what I was thinking. 👍

One thing to note is that this will create contacts even if creating the survey fails. A solution to that would be to just build the Contact records instead of saving them. I believe you'd simply remove the contact.save! from that method to just keep the changes in memory until the survey saves to the database.

You just run the commands like I said above. All your gems install side by side so you can always have more than one version installed.

Every Rails project has the version of Rails in the Gemfile that it will use separately from every other app. There's nothing you need to do to manage two different Rails versions.

The only thing you'll want to do is gem install rails to get the latest version and create your new project with rails new myapp. That will make sure the new project starts with Rails 5.1 (or whatever is the latest at the time).

You can also create apps with older versions of rails using rails _4.2.0_ new myapp

Rbenv and Rvm have pretty much nothing to do with this because they are for Ruby versions, not Rails. All of this is taken care of by Bundler.

When you switch apps to work on the correct versions will be automatically used, no changes required by you.

Interesting, glad you got it! :D

I'd like to, although I don't know much Swift and so I don't know how well I'll be able to cover it.

Deploying Webpacker to production is as simple as making sure you have Yarn installed on the server. No other changes needed for it which is awesome! :D

Definitely will be doing more on Vue in the future.

I figured. Hmm. This guy overrode the method to include a scope to fix his. https://github.com/plataformatec/devise/issues/3357

I know I've added a login key to this before without having to do this though.

Interesting, so the error was on the ActionDispatch Request object. Can you click the full trace tab and screenshot that too? Assuming your form passes in the student_id, I'd assume that'd be available.

Obvious thing: Did you restart Rails after changing the initializer?

Can you post the actual error?

Hey Giancarlo!

You generally have one of two options here:

1. A find or create select box which I talked about in an episode. This would let you search through all the existing users which you may not want depending on the application. (https://gorails.com/episodes/select-or-create-with-selectize-js)
2. The other option would be to create a form object where you pass in the contacts params and just pre-process it before you save the data. You can loop through the params for those emails the user typed in and if the user exists in the database, use that record. For the ones that you don't find, you can create new recipient records and attach them to your survey.

Option 2 sounds harder than it is. Really you're just looping through like params[:survey][:recipients] and converting those to records from your database.

Hmm, you might want to consider doing AJAX submits of those forms so that they don't have to step on each others toes like that. This would also solve your very minor URL issue where submitting a form takes you back to the same page with a very differnet URL.

Have you considered submitting the forms with AJAX?

Hey Steve!

Stripe has their own receipts that you can enable but they're very basic. You'll probably want to turn those off and send your own emails here.

Your code for this is exactly right. You'll want to pass in the charge / user information into the Mailer so that it has access to that to print it all out, but that's the only other thing you should really need to setup. I also added the PDF as an attachment to the email receipts for GoRails as well which has been nice. Might also consider doing that if you've got PDF receipts.

I haven't used the erb loader yet, but you might also consider just storing the json for the wizard pages in the DOM somewhere (probably in a head tag) that Webpack stuff loads. That's what I was showing in the VueJS examples of loading the data attribute for editing records, but since your JSON is more constant it would make more sense to put in the head instead of inside the body.

Hey Adrian,

What do you mean that it prevents comments from being created? Are you getting an error?

One thing I noticed is you're doing update attributes before you save, so it will try to save to the database twice there. The update_attributes call will hit the database. I believe you'd actually want:

@comment = Comment.new(comment_params)
@comment.assign_attributes(task_id: @task_id, user_id: current_user.id)
@comment.save!

That could also be written a few different ways, for example simply merging iin the task_id and user_id into params and making it a one-liner instead.

One other recommendation, when you're creating the other events / notifications you might consider doing this in an ActiveRecord transaction so you can get a bulk insert into the database which should be quicker than one-by-one.