The build failed.
CHANGES
---
Revision 8886 committed by gbuesing on 2008-02-17 00:35:49
Adding TimeWithZone#between?
M /trunk/activesupport/CHANGELOG
M /trunk/activesupport/test/core_ext/time_with_zone_test.rb
M /trunk/activesupport/lib/active_support/time_with_zone.rb
TEST FAILURES
Andrew,
I've seen problems like this, especially but not limited to when moving
an app from OS X to linux. It's the class auto-loading that's the
culprit. Rails' auto-load mechanism works great when you follow
convention, but if you stray (e.g., heavy use of modules) then
unexpected things
Also, if for whatever reason the request was retryed (by a proxy
perhaps) even a single user's actions could result in an unknown final
toggle state.
+1 for removal
On Feb 16, 2008 1:05 PM, Jarkko Laine <[EMAIL PROTECTED]> wrote:
> On 16.2.2008, at 20.43, Tammer Saleh wrote:
> > The correct solu
On 16.2.2008, at 20.43, Tammer Saleh wrote:
The correct solution is very easy in a restful application, where the
"publish" link should put params[:record][:published] = true to the
update action. But even in non-restful applications, having the link
post to #publish and #unpublish, depending on
On Feb 16, 2008 11:04 AM, Chris Nolan.ca <[EMAIL PROTECTED]> wrote:
> Can anyone see a reason why :include shouldn't be send through as
> well? I've done a quick fix on my system and it solved my problem,
> but before I try to submit a patch I wanted to see if anyone knew a
> reason it wasn't?
>
In trying to diagnose an error I was getting, I found
http://dev.rubyonrails.org/ticket/10211 added :order respect
http://dev.rubyonrails.org/ticket/10227 added :limit
These both patch the construct_scope methods in the ActiveRecord
association classes to pass through the @reflection.options for
I'd call that a bad practice, and I think it's commonly used only
because of the existence of AR's #toggle! method.
The "toggling" an admin flag via a web form is really "setting the
flag to true or false, depending on what the form thinks it currently
is". The problem with using #toggle! here i
On Feb 15, 8:40 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote:
> I wonder if I could suggest considering it when you look at ticket
> 6000. While this patch no longer applies cleanly, if you took the
> time to rebase it against trunk and resubmit it, I'm sure we'd be
> happy to apply it. Don
Hey Michael,
Thanks for letting me know what the case really is, I never had
thought of that. I guess it's a matter of communication, because I
think anyone in my situation at the time would have been disappointed
to find a ticket for the problem with a patch from a year ago that
wasn't applied
