Eric Mueller

I'm a bit confused by the lack of response here, this is a *major security problem*. Rails developers will not expect `can :read, Thing, :holder` to grant full read-access to...

It's not possible, as far as I can tell, but seems like the obvious assumption to make: ``` can :read, Thing, :foo cannot :read, Thing ``` Seems like the right...

The main story of concern: 1. Build a rails app, in say 2015. Use CanCanCan to build the authorization logic 2. continue working on that application for 5 years, building...

This is also contributing to a problem in distributed CI workflows, where disk workspaces need to be decompressed on fairly small containers - the total size of our installed gems...

Is this why getting the result of an `sinter` with 500k items takes 7 seconds without hiredis? I was a little confused, because using Ruby to parse the redis-cli response...

That other gem does some exception rewriting, and this one depends on the ActiveRecord::TransactionIsolationConflict exception, rather than the collection of other exceptions it wraps: https://github.com/qertoip/transaction_retry/blob/0cd0491a5ef2a8e1864522bb2760536da039cb55/lib/transaction_retry/active_record/base.rb#L33

At some point in the last 6 years, the example in question stopped being relevant because > expected `#.has_recieveddddddd?(:foo)` to return false, got # it's now checking for `true`, instead...

Ah, that explains it! Well, since it's still useful for now (and I expect rspec3 will be alive for a decade in some shops), I'm happy to throw together a...

> We could fix this with an additional check in the dynamic matcher, checking it's not a spy. I'm running into an awkwardness here that I didn't expect - the...

How's https://github.com/rspec/rspec-expectations/pull/1455 look?