Chris Oliver

You'll basically need to write your own JS to handle the DELETE request (my example wasn't fully functional). Don't use the data-confirm from Rails because that will conflict.

Here's a quick and dirty example that needs some refactoring, but should do the trick for you.

First you'll want to update the delete link and give it a behavior:

<td><%= link_to 'Destroy', user, data: { behavior: 'delete' } %></td>

Then you need to write some JS to listen for clicks on this link. It will do the following things

1. Display the dialog
2. Submits a DELETE to the url if confirmed (cancels if not confirmed)
3. Updates the dialog when the DELETE is successful

jQuery ->
  $("[data-behavior='delete']").on "click", (e) ->
    e.preventDefault()

    swal {
      title: 'Are you sure?'
      text: 'You will not be able to recover this imaginary file!'
      type: 'warning'
      showCancelButton: true
      confirmButtonColor: '#DD6B55'
      confirmButtonText: 'Yes, delete it!'
      cancelButtonText: 'No, cancel plx!'
      closeOnConfirm: false
      closeOnCancel: false
    }, (confirmed) =>
      if confirmed
        $.ajax(
          url: $(this).attr("href")
          dataType: "JSON"
          method: "DELETE"
          success: =>
            swal 'Deleted!', 'Your imaginary file has been deleted.', 'success'
            # TODO: Also remove the item from the page
        )

      else
        swal 'Cancelled', 'Your imaginary file is safe :)', 'error'
      return

In the success callback there, you'll want to also remove the item from the page, but I'll leave that up to you since it's application specific.

And that's it!

I ran into the same problem recently. Couldn't figure out what was wrong but maybe the gem had updated and it no longer recognized the option. You can install it manually and things work fine. Would love if someone finds a good solution for this.

Don't worry about uninstalling it because you might want to use 2.2.2 in the future. You installed a version manager so you can have multiple copies at once.

Just do this to install 1.8.7:

rbenv install 1.8.7
rbenv global 1.8.7
ruby -v

Oh sorry, I misunderstood! The best gems are always the ones where the name matches so the auto-require works nicely.This is an explanation of how the dashes work and how it affects the classes and modules of your gem.

http://guides.rubygems.org/...

http://stackoverflow.com/qu...

Yep! I think a lot of people do 'whatever-rails' and that's probably what I would recommend. You can do any naming scheme you want, but that seems to be the most common and it's good for SEO too.

Yeah, it's definitely designed for that purpose. You may need to figure out if you can make sure that the new edits don't go live immediately and can get marked as "to be reviewed". I'd give a shot, but I'd also say it isn't too hard to build your own if you find that doesn't meet your needs or it's inefficient for what you want.

Awesome! I'm glad I could be of help! :)

That's exactly what I do. Mine is a little different, but just make sure you return a class that inherits from CanCan::Ability and you'll be fine.

module Abilities
  def self.ability_for(user)
    if user
      if user.admin?
        AdminAbility.new(user)
      elsif user.editor?
        EditorAbility.new(user)
      elsif user.member?
        MemberAbility.new(user)
      end
    else
      GuestAbility.new
    end
  end
end

1. Unless it is an action (with a view), you always want to put those methods in the private section. You don't have to, but it's a good idea to.

2. Yep, that's it! That's basically just going to call the method instead of using the param directly. The method is the one that looks it up directly and then makes sure it gets converted to a sane integer.

You'll need to use a block and filter by the ID in the user's list.

This isn't exactly what you'll need, but this is one way of checking if a project is in the user's associated list. You can modify this for your authorization.

can :manage, Project do |project|
  user.projects.map(&:id).include? project.id
end

And here's more information on this: https://github.com/ryanb/cancan/wiki/Defining-Abilities-with-Blocks

The page method he suggested should work nicely. I have had this issue before on GoRails too.

You can add this to the bottom of your controller or ApplicationController and just replace all the params[:page] references with this method page

def page
  p = params[:page].to_i
  p > 1 ? p : 1
end

I'm kinda surprised will_paginate doesn't handle this internally.

Absolutely can. I'm a fan of Pundit over CanCan, but choose whichever one you are more comfortable with.

You can just filter them out with a scope that says where clocked_out IS NOT NULL. That should do the trick.

Hey Gareth, when you do a soft delete, there should be nothing that happens other than a database field called deleted_at getting set. This won't affect images at all because they should only get removed when destroyed. Are the images actually getting removed?

You could calculate the total and cache it. That would make for editing to be easier. For totalling, that might make it easier where the total defaults to 0 until the clock_out time is added so the sums are always correct.

I don't see any real downsides to that off the top of my head. Do you?

You could do

def set_uuid
  return if persisted? # Don't run if this record has already been saved

    begin
      self.minecraft_uuid = MojangApi.get_profile_from_name(minecraft_uuid).uuid        
     rescue Exception => e
     end
end

You could use something like Pundit to count the number of subscriptions and cause something else to happen or prevent it from working at that point. Check out this episode https://gorails.com/episodes/authorization-with-pundit

Recurring events get complicated quickly! :)

You may need to do a find_or_create for all the recursivedates when you do an edit. It also might be easier to delete all the existing ones before adding the new dates. That will save you some trouble. I'd take a look at how Google Calendar does it and work backwards from there if you like the way it works.

I think they may calculate on the fly the recurring ones so they don't have to insert records for X years into the future and your calendar will always work. They probably separate individual dates and recurring ones and query for both each time the page renders.

That's not a bad solution for now to handle it manually.

In general, you simply want to lookup and validate the UUID only when the username changes. There are a bunch of different ways you could do that, but I forgot that you could use ActiveModel::Dirty to check if the username field had changed. This works because when you set the field the first time it technically "changed" from nil to one the user submitted.

before_validation set_uuid, if: :username_changed?
validates :minecraft_uuid, presence: true

def set_uuid
    begin
      self.minecraft_uuid = MojangApi.get_profile_from_name(minecraft_uuid).uuid        
     rescue Exception => e
     end
end

The best way to handle that is authorization with Pundit. You can load up the project and verify if the current user has access to the project based upon the associations set. They will be able to change the ID in the url, but Pundit will throw an error if they try to access one they aren't a part of. Here's an episode on Authorization With Pundit that I did a while back.