Chris Oliver

Haha! Yeah no worries man. Calendars get tricky at a point when you're doing all day events and so on.

The main thing to understand here is that simple_calendar is just sorting the objects you give it by the time attributes, so they must all have valid times and dates. All-Day events should sort to the top, which means their start time should always be 12:00am. If that is nil or some other value in the database, they will sort nil or those other values and will be incorrectly placed.

Since it does the sorting internally, any pre-sorting you might have done will be ignored. Your all-day sort to the top is going to be ignored since simple calendar can't know ahead of time which day to place the event. As long as you get your times right for each event, simple calendar will take care of the rest.

Hey Stephen,

I would just make a custom before_action:

before_action :authenticate_company_or_contractor!

def authenticate_company_or_contractor!
  redirect_to root_path, alert: "You aren't allowed to do that" unless company_signed_in? || contractor_signed_in?
end

And voila. You're done. This is basically the exact same thing that authenticate_user! (or company or contractor, etc) implement behind the scenes. Nothin fancy!

Ah ha! That would explain it. :) Should have asked about that, but I assume that people are using the latest too quickly sometimes.

You have two options for that:

1. I would just do like I showed in the episode by creating your virtual array of events for recurring ones. The all-day events you would want to handle a little differently and to actually be passed into simple_calendar with the start time as 12:00am and 11:59pm for the end time. No overriding necessary as these will obviously be sorted to the top automatically. Actually, if the user checks the "all day" box you can just save those values in the database and then you don't have to do any special code for them.

2. You could override the method. Just redefine the calendar object and override that method. Generally not a great idea as you may run into problems when the gem gets updated in the future.

It definitely works. Just tested a fresh install of simple_calendar and both month_calendar and week_calendar that I tested work as expected. https://cl.ly/kW2w One record in the database but it gets rendered 4 times, one for each day it spans.

That means that your start_time and end_time attributes must be the culprit in your last example I guess. What do your records look like?

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.