2
true
2009-12-11T21:20:16+00:00
19965
2010-01-15T00:00:00+00:00
50064
3564
activerercorderror-broke-errorsaddattribute-type-default-message
3
8994
resolved
ActiveRercord::Error broke errors.add(attribute, type, :default => message)
2009-12-16T20:19:42+00:00
424
Joshua Peek
José Valim
http://rails.lighthouseapp.com/projects/8994/tickets/3564
2.3.6
Previously, this worked:
errors.add(:email, :not_found, :default => "not found")
Today, it does not work because it completely ignores the :not_found type and does the I18n lookup using "not found" instead. A patch with a fix and test case is attached.
Previously, this worked:
errors.add(:email, :not_found, :default => "not found")
Today, it does not work because it completely ignores the :not_found type and does the I18n lookup using "not found" instead. A patch with a fix and test case is attached.
<div><p>Previously, this worked:</p>
<p>errors.add(:email, :not_found, :default => "not found")</p>
<p>Today, it does not work because it completely ignores the
:not_found type and does the I18n lookup using "not found" instead.
A patch with a fix and test case is attached.</p></div>
0
true
2009-10-30T02:06:01+00:00
19965
2010-01-15T00:00:00+00:00
50064
3444
i18n-should-accept-to-be-given-and-not-whiny-about-it
2
8994
wontfix
I18n should accept ~ to be given and not whiny about it
2009-12-16T19:13:20+00:00
19965
José Valim
José Valim
http://rails.lighthouseapp.com/projects/8994/tickets/3444
2.3.6
@@@ ruby
en:
flash:
failed: ~
@@@
The code above does not work, since I18n still returns me a "translation missing" message. That would be useful since we can overwrite in the application messages set in plugins.
@@@ ruby
en:
flash:
failed: ~
@@@
The code above does not work, since I18n still returns me a "translation missing" message. That would be useful since we can overwrite in the application messages set in plugins.
<div><pre>
<code class="ruby">en:
flash:
failed: ~</code>
</pre>
<p>The code above does not work, since I18n still returns me a
"translation missing" message. That would be useful since we can
overwrite in the application messages set in plugins.</p></div>
6601
0
false
2009-10-30T01:54:13+00:00
19965
2010-01-15T00:00:00+00:00
50064
3443
locales-in-gemsplugins-should-not-have-higher-priority-than-application-locale-files
1
8994
new
gems i18n locale
Locales in gems/plugins should not have higher priority than application locale files
2009-12-15T20:17:00+00:00
19965
José Valim
José Valim
Carl Lerche
http://rails.lighthouseapp.com/projects/8994/tickets/3443
2.3.6
Since gems/plugins locales files are later in the load path, we cannot overwrite plugins/gems configurations.
Since gems/plugins locales files are later in the load path, we cannot overwrite plugins/gems configurations.
<div><p>Since gems/plugins locales files are later in the load path, we
cannot overwrite plugins/gems configurations.</p></div>
85
2
true
2009-09-01T12:22:13+01:00
19965
3128
check-for-primary-key-in-habtm-when-the-association-is-defined
132281
8994
resolved
2.3.4 3.0 habtm
Check for primary key in habtm when the association is defined
2009-11-23T18:42:55+00:00
17393
Repository
José Valim
Jeremy Kemper
http://rails.lighthouseapp.com/projects/8994/tickets/3128
In this commit:
http://github.com/rails/rails/commit/9d51f6286680b832b0df5e3ce288575214c1de59
We started to check if the primary key in habtm was defined and raise an error if it does. However, the current implementation checks for it every time we insert a record for the first time, per association and then per request.
The patch attached changes it, so it's checked only when the association is defined. I was planning to move the logic to Reflection.check_validity!, but this method is invoked every time an association proxy is created. I tried to make check_validity! to be invoked just on load as well, but :through validity can only be ensured in runtime (when all records are supposed to be loaded).
Patch is for master and 2-3-stable.
In this commit:
http://github.com/rails/rails/commit/9d51f6286680b832b0df5e3ce288575214c1de59
We started to check if the primary key in habtm was defined and raise an error if it does. However, the current implementation checks for it every time we insert a record for the first time, per association and then per request.
The patch attached changes it, so it's checked only when the association is defined. I was planning to move the logic to Reflection.check_validity!, but this method is invoked every time an association proxy is created. I tried to make check_validity! to be invoked just on load as well, but :through validity can only be ensured in runtime (when all records are supposed to be loaded).
Patch is for master and 2-3-stable.
<div><p>In this commit:</p>
<p><a href=
"http://github.com/rails/rails/commit/9d51f6286680b832b0df5e3ce288575214c1de59">
http://github.com/rails/rails/commit/9d51f6286680b832b0df5e3ce28857...</a></p>
<p>We started to check if the primary key in habtm was defined and
raise an error if it does. However, the current implementation
checks for it every time we insert a record for the first time, per
association and then per request.</p>
<p>The patch attached changes it, so it's checked only when the
association is defined. I was planning to move the logic to
Reflection.check_validity!, but this method is invoked every time
an association proxy is created. I tried to make check_validity! to
be invoked just on load as well, but :through validity can only be
ensured in runtime (when all records are supposed to be
loaded).</p>
<p>Patch is for master and 2-3-stable.</p></div>
424
1
true
2009-11-10T13:08:31+00:00
19965
2010-01-15T00:00:00+00:00
50064
3477
activerecorderror-does-not-allow-values-to-add-errors
3
8994
resolved
2.3.5 activerecord errors
ActiveRecord::Error does not allow values to add errors
2009-11-10T18:27:36+00:00
424
Joshua Peek
José Valim
Joshua Peek
http://rails.lighthouseapp.com/projects/8994/tickets/3477
2.3.6
(Message from #3147 by Chris Hapgood)
Briefly: an error on an attribute cannot be set as the result of an exception computing the value of the attribute.
For example:
def v
compute_it
rescue
errors.add(:v, "Dadgummit")
end
When compute_it raise an exception, ActiveRecord::Error#initialize references v, which in turn raises another exception, which adds another error, which in turn proves that my stack is not infinitely deep.
Is it reasonable to assume that ActiveRecord::Error instances can reference its erroneous attribute's value? If so, the above pattern won't work and instead a sentinel value will need to be set (U-G-L-Y).
(Message from #3147 by Chris Hapgood)
Briefly: an error on an attribute cannot be set as the result of an exception computing the value of the attribute.
For example:
def v
compute_it
rescue
errors.add(:v, "Dadgummit")
end
When compute_it raise an exception, ActiveRecord::Error#initialize references v, which in turn raises another exception, which adds another error, which in turn proves that my stack is not infinitely deep.
Is it reasonable to assume that ActiveRecord::Error instances can reference its erroneous attribute's value? If so, the above pattern won't work and instead a sentinel value will need to be set (U-G-L-Y).
<div><p>(Message from <a href="/projects/8994/tickets/3147" title=
"Ticket #3147">#3147</a> by Chris Hapgood)</p>
<p>Briefly: an error on an attribute cannot be set as the result of
an exception computing the value of the attribute.</p>
<p>For example:</p>
<p>def v compute_it rescue errors.add(:v, "Dadgummit") end</p>
<p>When compute_it raise an exception,
ActiveRecord::Error#initialize references v, which in turn raises
another exception, which adds another error, which in turn proves
that my stack is not infinitely deep.</p>
<p>Is it reasonable to assume that ActiveRecord::Error instances
can reference its erroneous attribute's value? If so, the above
pattern won't work and instead a sentinel value will need to be set
(U-G-L-Y).</p></div>
8406
3
true
2009-07-17T08:08:58+01:00
19965
2009-08-31T00:00:00+01:00
41987
2904
avoid-copying-errors-from-child-to-parent-on-autosave
2
8994
invalid
Avoid copying errors from child to parent on autosave
2009-09-22T13:52:51+01:00
19965
José Valim
José Valim
Eloy Duran
http://rails.lighthouseapp.com/projects/8994/tickets/2904
2.3.4
This patch solves the problem discussed on the mailing list where errors were being copied from child to parent on autosave, which is difficult to deal in I18n because it lacks fallback and does string concatenation:
http://groups.google.com/group/rubyonrails-core/browse_thread/thread/90f9eccf9ca35f60
The displaying of error messages on associations was then moved to error_messages_for, since it's basically a view concern. In order to achieve this, two options were added in error_messages_for: :associations and :except.
The first allows me to show nested association messages. Consider that a project has many tasks with the setup as below:
@@@ ruby
project = Project.new
task1 = project.tasks.build
task2 = project.tasks.build
project.save #=> false
project.errors #=> { :title => "can't be blank", :tasks => "is invalid" }
task1.errors #=> { :name => "can't be blank" }
task2.errors #=> { :name => "can't be blank" }
# error_messages_for below prints something like:
#
# + Title can't be blank
# + Tasks
# + Name can't be blank
#
error_messages_for :project, :associations => :tasks
@@@
Please notice two things from the code above:
1) Even if the two tasks have the message "Name can't be blank", the message is shown just once.
2) The "Tasks is invalid" message from project is not showed, since we are already showing the association errors.
The item (2) is handled internally using the option :except. If you give an attribute (or an array of attributes) to :except, the error messages for those attributes are not shown.
This patch solves the problem discussed on the mailing list where errors were being copied from child to parent on autosave, which is difficult to deal in I18n because it lacks fallback and does string concatenation:
http://groups.google.com/group/rubyonrails-core/browse_thread/thread/90f9eccf9ca35f60
The displaying of error messages on associations was then moved to error_messages_for, since it's basically a view concern. In order to achieve this, two options were added in error_messages_for: :associations and :except.
The first allows me to show nested association messages. Consider that a project has many tasks with the setup as below:
@@@ ruby
project = Project.new
task1 = project.tasks.build
task2 = project.tasks.build
project.save #=> false
project.errors #=> { :title => "can't be blank", :tasks => "is invalid" }
task1.errors #=> { :name => "can't be blank" }
task2.errors #=> { :name => "can't be blank" }
# error_messages_for below prints something like:
#
# + Title can't be blank
# + Tasks
# + Name can't be blank
#
error_messages_for :project, :associations => :tasks
@@@
Please notice two things from the code above:
1) Even if the two tasks have the message "Name can't be blank", the message is shown just once.
2) The "Tasks is invalid" message from project is not showed, since we are already showing the association errors.
The item (2) is handled internally using the option :except. If you give an attribute (or an array of attributes) to :except, the error messages for those attributes are not shown.
<div><p>This patch solves the problem discussed on the mailing list
where errors were being copied from child to parent on autosave,
which is difficult to deal in I18n because it lacks fallback and
does string concatenation:</p>
<p><a href="http://groups.google.com/group/rubyonrails-core/browse_thread/thread/90f9eccf9ca35f60">
http://groups.google.com/group/r...</a></p>
<p>The displaying of error messages on associations was then moved
to error_messages_for, since it's basically a view concern. In
order to achieve this, two options were added in
error_messages_for: :associations and :except.</p>
<p>The first allows me to show nested association messages.
Consider that a project has many tasks with the setup as below:</p>
<pre><code class="ruby">
project = Project.new
task1 = project.tasks.build
task2 = project.tasks.build
project.save #=> false
project.errors #=> { :title => "can't be blank", :tasks => "is invalid" }
task1.errors #=> { :name => "can't be blank" }
task2.errors #=> { :name => "can't be blank" }
# error_messages_for below prints something like:
#
# + Title can't be blank
# + Tasks
# + Name can't be blank
#
error_messages_for :project, :associations => :tasks
</code></pre>
<p>Please notice two things from the code above:</p>
<p>1) Even if the two tasks have the message "Name can't be blank",
the message is shown just once.</p>
<p>2) The "Tasks is invalid" message from project is not showed,
since we are already showing the association errors.</p>
<p>The item (2) is handled internally using the option :except. If
you give an attribute (or an array of attributes) to :except, the
error messages for those attributes are not shown.</p></div>
8406
1
true
2009-07-09T09:59:44+01:00
19965
2010-01-15T00:00:00+00:00
50064
2889
rename-_delete-to-_destroy-in-nested-attributes
9
8994
resolved
Rename _delete to _destroy in nested attributes
2009-09-13T02:33:46+01:00
17393
Repository
José Valim
Eloy Duran
http://rails.lighthouseapp.com/projects/8994/tickets/2889
2.3.6
When nested attributes was released in 2.3 it came with a small inconsistency. The DSL uses :allow_destroy, the method called in the associated object is :destroy but the trigger is called *_delete*. This patch changes _delete to _destroy but adds a deprecation warning. Documentation was also updated.
As already discussed in the mailing list, someone already wanted to add a _delete behavior that will actually delete the associated record. So renaming _delete to _destroy now makes room for improvements in the future.
When nested attributes was released in 2.3 it came with a small inconsistency. The DSL uses :allow_destroy, the method called in the associated object is :destroy but the trigger is called *_delete*. This patch changes _delete to _destroy but adds a deprecation warning. Documentation was also updated.
As already discussed in the mailing list, someone already wanted to add a _delete behavior that will actually delete the associated record. So renaming _delete to _destroy now makes room for improvements in the future.
<div><p>When nested attributes was released in 2.3 it came with a small
inconsistency. The DSL uses :allow_destroy, the method called in
the associated object is :destroy but the trigger is called
<em>_delete</em>. This patch changes <em>delete to</em> destroy but
adds a deprecation warning. Documentation was also updated.</p>
<p>As already discussed in the mailing list, someone already wanted
to add a <em>delete behavior that will actually delete the
associated record. So renaming</em> delete to _destroy now makes
room for improvements in the future.</p></div>
85
2
true
2009-09-02T19:58:21+01:00
19965
27004
3136
change-activerecord-callbacks-to-use-faster-implementation-and-speed-up-observers
9
8994
resolved
activerecord callbacks observer
Change ActiveRecord callbacks to use faster implementation and speed up Observers
2009-09-11T21:03:23+01:00
19965
José Valim
José Valim
Jeremy Kemper
http://rails.lighthouseapp.com/projects/8994/tickets/3136
3.0
7400
0
false
2009-09-08T16:47:57+01:00
19965
3167
flexible-formatting-for-ar-validations-should-be-on-master
32886
8994
new
3.0 activerecord validations
Flexible formatting for AR validations should be on master
2009-09-08T16:48:01+01:00
19965
José Valim
José Valim
Sven Fuchs
http://rails.lighthouseapp.com/projects/8994/tickets/3167
https://rails.lighthouseapp.com/projects/8994/tickets/1687-flexible-formatting-for-ar-validation-error-messages
https://rails.lighthouseapp.com/projects/8994/tickets/1687-flexible-formatting-for-ar-validation-error-messages
<div><p><a href=
"https://rails.lighthouseapp.com/projects/8994/tickets/1687-flexible-formatting-for-ar-validation-error-messages">
https://rails.lighthouseapp.com/projects/8994/tickets/1687-flexible...</a></p></div>
1
1
true
2008-05-16T18:21:08+01:00
19965
2009-03-18T00:00:00+00:00
9901
209
added-environment-options-to-config-gem
11164
8994
invalid
2.2.2 bug
Added :environment options to config.gem
2009-08-14T03:38:39+01:00
21993
Donald Ball
José Valim
Rick
http://rails.lighthouseapp.com/projects/8994/tickets/209
2.1.1
This way we can specify which gems will be loaded in each environment. This is useful since we don't want ZenTest or ruby-debug running in production.
Usage:
config.gem "ZenTest", :environment => :test
config.gem "ruby-debug", :environment => [:development, :test]
Tests included.
This way we can specify which gems will be loaded in each environment. This is useful since we don't want ZenTest or ruby-debug running in production.
Usage:
config.gem "ZenTest", :environment => :test
config.gem "ruby-debug", :environment => [:development, :test]
Tests included.
<div><p>
This way we can specify which gems will be loaded in each environment. This is useful since we don't want ZenTest or ruby-debug running in production.
</p><p>
Usage:
</p><p>
config.gem "ZenTest", :environment => :test
</p><p>
config.gem "ruby-debug", :environment => [:development, :test]
</p><p>
Tests included.
</p></div>
1
true
2009-08-09T18:26:00+01:00
19965
2009-08-31T00:00:00+01:00
41987
3025
modelhuman_attribute_name-does-not-accept-symbols
20
8994
resolved
activerecord verified
Model#human_attribute_name does not accept symbols
2009-08-09T23:57:31+01:00
19965
José Valim
José Valim
http://rails.lighthouseapp.com/projects/8994/tickets/3025
2.3.4
Post.human_attribute_name(:body) does not work, I always have to add convert :body to string. Would be nice if the API accept symbols too.
Post.human_attribute_name(:body) does not work, I always have to add convert :body to string. Would be nice if the API accept symbols too.
<div><p>Post.human_attribute_name(:body) does not work, I always have to
add convert :body to string. Would be nice if the API accept
symbols too.</p></div>
1
true
2009-08-08T11:56:12+01:00
19965
2009-08-31T00:00:00+01:00
41987
3006
patch-to-fix-broken-http-digest-authentication
19
8994
resolved
2.x 3.0 actioncontroller
Patch to fix broken HTTP Digest Authentication
2009-08-09T16:13:01+01:00
17393
Repository
José Valim
http://rails.lighthouseapp.com/projects/8994/tickets/3006
2.3.4
Current HTTP Digest Authentication does not work with some browser/servers combinations.
For example, Webrick uses the full REQUEST_URI, while a browser like Safari or Firefox only send the relative_uri. In this case, HTTP Digest won't work.
On the other hand, IE sends the full REQUEST_URI, so it may not work with servers like mongrel or thin.
This patch attempts to let it flexible enough to work with a different combination of servers/browsers, without changing any security rule.
I tested in "real life" with Firefox on Linux on both webrick and thin. Would be nice if some tests would be executed with Safari and IE with both servers.
For some guidance, you could follow Ryan Daigle tutorial to setup: http://ryandaigle.com/articles/2009/1/30/what-s-new-in-edge-rails-http-digest-authentication
Current HTTP Digest Authentication does not work with some browser/servers combinations.
For example, Webrick uses the full REQUEST_URI, while a browser like Safari or Firefox only send the relative_uri. In this case, HTTP Digest won't work.
On the other hand, IE sends the full REQUEST_URI, so it may not work with servers like mongrel or thin.
This patch attempts to let it flexible enough to work with a different combination of servers/browsers, without changing any security rule.
I tested in "real life" with Firefox on Linux on both webrick and thin. Would be nice if some tests would be executed with Safari and IE with both servers.
For some guidance, you could follow Ryan Daigle tutorial to setup: http://ryandaigle.com/articles/2009/1/30/what-s-new-in-edge-rails-http-digest-authentication
<div><p>Current HTTP Digest Authentication does not work with some
browser/servers combinations.</p>
<p>For example, Webrick uses the full REQUEST_URI, while a browser
like Safari or Firefox only send the relative_uri. In this case,
HTTP Digest won't work.</p>
<p>On the other hand, IE sends the full REQUEST_URI, so it may not
work with servers like mongrel or thin.</p>
<p>This patch attempts to let it flexible enough to work with a
different combination of servers/browsers, without changing any
security rule.</p>
<p>I tested in "real life" with Firefox on Linux on both webrick
and thin. Would be nice if some tests would be executed with Safari
and IE with both servers.</p>
<p>For some guidance, you could follow Ryan Daigle tutorial to
setup: <a href="http://ryandaigle.com/articles/2009/1/30/what-s-new-in-edge-rails-http-digest-authentication">
http://ryandaigle.com/articles/2...</a></p></div>
19965
1
true
2009-08-08T17:47:05+01:00
19965
27004
3008
rails-generators-does-not-take-into-consideration-activerecordsessionstoresessiontable_name
2
8994
resolved
Rails generators does not take into consideration ActiveRecord::SessionStore::Session.table_name
2009-08-09T05:18:43+01:00
17393
Repository
José Valim
José Valim
http://rails.lighthouseapp.com/projects/8994/tickets/3008
3.0
The patch applied on #2745 should also be ported and applied on current edge.
The patch applied on #2745 should also be ported and applied on current edge.
<div><p>The patch applied on <a href="/projects/8994/tickets/2745" title="Ticket #2745">#2745</a> should also be ported and applied on
current edge.</p></div>
1366
1
true
2009-06-12T20:35:21+01:00
19965
9903
2795
has_one-with-a-belongs_to-as-source-association
1812
8994
wontfix
has_one with a belongs_to as source association
2009-08-08T12:11:06+01:00
19965
José Valim
José Valim
Pratik
http://rails.lighthouseapp.com/projects/8994/tickets/2795
2.x
This patches allow you to use a has_one association with a belongs_to as source. Assuming that House belongs to City that belongs to Country:
@@@ ruby
class House
belongs_to :city
has_one :country, :through => :city
end
class City
belongs_to :country
end
class Country
end
@@@
The following works in Rails current versions (preload case):
@@@ ruby
House.all(:include => :country)
@@@
The following DOES NOT work on Rails current version and is fixed by this patch (non-preload case):
@@@ ruby
House.all(:include => :country, :conditions => ["countries.name = ?", "Brazil"])
@@@
However, as I talked with Pratik and Koz on IRC, we could simply do this:
@@@ ruby
House.all(:include => { :city => :country }, :conditions => ["countries.name = ?", "Brazil"])
@@@
I've created the patch because I've needed this behavior in geokit-rails, which was later fixed to work with the { :city => :country } case, but currently it has no use and it should not be applied until someone comes up with a use case for it.
This ticket is just to document the patch.
This patches allow you to use a has_one association with a belongs_to as source. Assuming that House belongs to City that belongs to Country:
@@@ ruby
class House
belongs_to :city
has_one :country, :through => :city
end
class City
belongs_to :country
end
class Country
end
@@@
The following works in Rails current versions (preload case):
@@@ ruby
House.all(:include => :country)
@@@
The following DOES NOT work on Rails current version and is fixed by this patch (non-preload case):
@@@ ruby
House.all(:include => :country, :conditions => ["countries.name = ?", "Brazil"])
@@@
However, as I talked with Pratik and Koz on IRC, we could simply do this:
@@@ ruby
House.all(:include => { :city => :country }, :conditions => ["countries.name = ?", "Brazil"])
@@@
I've created the patch because I've needed this behavior in geokit-rails, which was later fixed to work with the { :city => :country } case, but currently it has no use and it should not be applied until someone comes up with a use case for it.
This ticket is just to document the patch.
<div><p>This patches allow you to use a has_one association with a
belongs_to as source. Assuming that House belongs to City that
belongs to Country:</p>
<pre><code class="ruby">
class House
belongs_to :city
has_one :country, :through => :city
end
class City
belongs_to :country
end
class Country
end
</code></pre>
<p>The following works in Rails current versions (preload
case):</p>
<pre><code class="ruby">
House.all(:include => :country)
</code></pre>
<p>The following DOES NOT work on Rails current version and is
fixed by this patch (non-preload case):</p>
<pre><code class="ruby">
House.all(:include => :country, :conditions => ["countries.name = ?", "Brazil"])
</code></pre>
<p>However, as I talked with Pratik and Koz on IRC, we could simply
do this:</p>
<pre><code class="ruby">
House.all(:include => { :city => :country }, :conditions => ["countries.name = ?", "Brazil"])
</code></pre>
<p>I've created the patch because I've needed this behavior in
geokit-rails, which was later fixed to work with the { :city =>
:country } case, but currently it has no use and it should not be
applied until someone comes up with a use case for it.</p>
<p>This ticket is just to document the patch.</p></div>
8406
1
true
2009-04-01T11:55:25+01:00
19965
9903
2391
allow-strings-to-be-sent-as-collection-to-select
1550
8994
committed
actionview form_for select tiny
Allow strings to be sent as collection to select
2009-05-15T04:31:15+01:00
17393
Repository
José Valim
Eloy Duran
http://rails.lighthouseapp.com/projects/8994/tickets/2391
2.x
Why?
The main reason is to allow the following:
@@@ ruby
fields_for @post do |f|
f.select(:category_id, grouped_options_for_select(...))
end
@@@
Since grouped_options_for_select returns a string, prior to this patch this wouldn't work. We would have to use select_tag method, which is not very friendly since it does not generate names properly (post[category]) and does not work with nested attributes as well (it wouldn't generate blog[post][0][category]).
Why?
The main reason is to allow the following:
@@@ ruby
fields_for @post do |f|
f.select(:category_id, grouped_options_for_select(...))
end
@@@
Since grouped_options_for_select returns a string, prior to this patch this wouldn't work. We would have to use select_tag method, which is not very friendly since it does not generate names properly (post[category]) and does not work with nested attributes as well (it wouldn't generate blog[post][0][category]).
<div><p>Why?</p>
<p>The main reason is to allow the following:</p>
<pre><code class="ruby">
fields_for @post do |f|
f.select(:category_id, grouped_options_for_select(...))
end
</code></pre>
<p>Since grouped_options_for_select returns a string, prior to this
patch this wouldn't work. We would have to use select_tag method,
which is not very friendly since it does not generate names
properly (post[category]) and does not work with nested attributes
as well (it wouldn't generate blog[post][0][category]).</p></div>
2
true
2009-03-17T00:58:10+00:00
19965
9903
2262
associations-are-picking-the-wrong-class
1440
8994
invalid
activerecord associations patch small tests
Associations are picking the wrong class
2009-05-08T00:11:46+01:00
17477
Frederick Cheung
José Valim
http://rails.lighthouseapp.com/projects/8994/tickets/2262
2.x
This is being discussed on the mailing list:
http://groups.google.com/group/rubyonrails-core/browse_thread/thread/37e25977536c65a2
### Problem ###
@@@ ruby
class User < ActiveRecord::Base
end
class Admin::User < ActiveRecord::Base
end
class Account < ActiveRecord::Base
belongs_to :user
end
@@@
When I was calling Account.new.build_user, it was trying to create a
new Admin::User because the default class_name is just "User".
### Where? ###
Rails 2.3.2
### Why this is a problem? ###
Let's suppose I'm building an application (without using namespaced models at all) and then I install a plugin that has Plugin::User. My associations will start to pick Plugin::User, and this is really hard to track down.
### Solution? ###
I propose a solution where all associations :class_name is, by default, namespaced. So:
@@@ ruby
# have default class_name of ::User
class Account < ActiveRecord::Base; belongs_to :user; end
# have default class_name of ::Admin::User
class Admin::Account < ActiveRecord::Base; belongs_to :user; end
@@@
### Compatibility? ###
It will break apps that are relying in this wrong behavior. The good point is that the error will be raised when the application starts (can't find association error). The way it's now, takes quite sometime for you to discover that Account was trying to build a Admin::User instead of User.
This is being discussed on the mailing list:
http://groups.google.com/group/rubyonrails-core/browse_thread/thread/37e25977536c65a2
### Problem ###
@@@ ruby
class User < ActiveRecord::Base
end
class Admin::User < ActiveRecord::Base
end
class Account < ActiveRecord::Base
belongs_to :user
end
@@@
When I was calling Account.new.build_user, it was trying to create a
new Admin::User because the default class_name is just "User".
### Where? ###
Rails 2.3.2
### Why this is a problem? ###
Let's suppose I'm building an application (without using namespaced models at all) and then I install a plugin that has Plugin::User. My associations will start to pick Plugin::User, and this is really hard to track down.
### Solution? ###
I propose a solution where all associations :class_name is, by default, namespaced. So:
@@@ ruby
# have default class_name of ::User
class Account < ActiveRecord::Base; belongs_to :user; end
# have default class_name of ::Admin::User
class Admin::Account < ActiveRecord::Base; belongs_to :user; end
@@@
### Compatibility? ###
It will break apps that are relying in this wrong behavior. The good point is that the error will be raised when the application starts (can't find association error). The way it's now, takes quite sometime for you to discover that Account was trying to build a Admin::User instead of User.
<div><p>This is being discussed on the mailing list:</p>
<p><a href="http://groups.google.com/group/rubyonrails-core/browse_thread/thread/37e25977536c65a2">
http://groups.google.com/group/r...</a></p>
<h3>Problem</h3>
<pre><code class="ruby">
class User < ActiveRecord::Base
end
class Admin::User < ActiveRecord::Base
end
class Account < ActiveRecord::Base
belongs_to :user
end
</code></pre>
<p>When I was calling Account.new.build_user, it was trying to
create a new Admin::User because the default class_name is just
"User".</p>
<h3>Where?</h3>
<p>Rails 2.3.2</p>
<h3>Why this is a problem?</h3>
<p>Let's suppose I'm building an application (without using
namespaced models at all) and then I install a plugin that has
Plugin::User. My associations will start to pick Plugin::User, and
this is really hard to track down.</p>
<h3>Solution?</h3>
<p>I propose a solution where all associations :class_name is, by
default, namespaced. So:</p>
<pre><code class="ruby">
# have default class_name of ::User
class Account < ActiveRecord::Base; belongs_to :user; end
# have default class_name of ::Admin::User
class Admin::Account < ActiveRecord::Base; belongs_to :user; end
</code></pre>
<h3>Compatibility?</h3>
<p>It will break apps that are relying in this wrong behavior. The
good point is that the error will be raised when the application
starts (can't find association error). The way it's now, takes
quite sometime for you to discover that Account was trying to build
a Admin::User instead of User.</p></div>
1
true
2009-01-11T10:14:58+00:00
19965
2009-01-31T00:00:00+00:00
1731
make-enable_starttls_auto-opt-in-in-actionmailer
0
8994
resolved
2.2 actionmailer "getaddrinfo: name or service not known" smtp socketerror
Make enable_starttls_auto opt-in in ActionMailer
2009-05-06T01:10:32+01:00
56167
Mark Glossop
José Valim
http://rails.lighthouseapp.com/projects/8994/tickets/1731
This commit:
http://github.com/rails/rails/commit/732c724df61bc8b780dc42817625b25a321908e4
Enabled automatically STARTTLS in SMPT server making some applications break.
This patch makes enable_starttls_auto opt-in.
This commit:
http://github.com/rails/rails/commit/732c724df61bc8b780dc42817625b25a321908e4
Enabled automatically STARTTLS in SMPT server making some applications break.
This patch makes enable_starttls_auto opt-in.
<div><p>This commit:</p>
<p><a href="http://github.com/rails/rails/commit/732c724df61bc8b780dc42817625b25a321908e4">
http://github.com/rails/rails/co...</a></p>
<p>Enabled automatically STARTTLS in SMPT server making some
applications break.</p>
<p>This patch makes enable_starttls_auto opt-in.</p></div>
1366
1
true
2009-04-18T13:51:32+01:00
19965
9903
2517
time_zone_select-documentation-is-outdated
1513
8994
wontfix
2.3.2 action_view doc documentation timezone tiny
time_zone_select documentation is outdated
2009-04-18T20:10:10+01:00
1366
Pratik
José Valim
Pratik
http://rails.lighthouseapp.com/projects/8994/tickets/2517
2.x
Currently, the documentation and examples uses the TimeZone object, while it should refer to the ActiveSupport::TimeZone object.
Patch attached.
Currently, the documentation and examples uses the TimeZone object, while it should refer to the ActiveSupport::TimeZone object.
Patch attached.
<div><p>Currently, the documentation and examples uses the TimeZone
object, while it should refer to the ActiveSupport::TimeZone
object.</p>
<p>Patch attached.</p></div>
1
true
2009-04-01T10:30:14+01:00
19965
9903
2390
object-names-with-underscore-do-the-wrong-lookup-in-i18n-on-error_messages_for
1549
8994
committed
actionview bug error_messages_for i18n verified
Object names with underscore do the wrong lookup in I18n on error_messages_for
2009-04-05T10:45:55+01:00
17393
Repository
José Valim
http://rails.lighthouseapp.com/projects/8994/tickets/2390
2.x
If I have an object name like "book_seller." On error_messages_for it will search for "book seller" instead of "book_seller".
A quick solution is two maintain both on I18n files:
activerecord:
models:
book_seller "Book seller"
book seller: "Book seller"
This patch fix that.
If I have an object name like "book_seller." On error_messages_for it will search for "book seller" instead of "book_seller".
A quick solution is two maintain both on I18n files:
activerecord:
models:
book_seller "Book seller"
book seller: "Book seller"
This patch fix that.
<div><p>If I have an object name like "book_seller." On
error_messages_for it will search for "book seller" instead of
"book_seller".</p>
<p>A quick solution is two maintain both on I18n files:</p>
<p>activerecord:</p>
<pre>
<code>models:
book_seller "Book seller"
book seller: "Book seller"
</code>
</pre>
<p>This patch fix that.</p></div>
424
1
true
2009-02-05T18:00:31+00:00
19965
2009-01-31T00:00:00+00:00
1886
html-fallback-when-format-is-js-should-be-also-localized
47
8994
resolved
actionpack localization
HTML fallback when format is :js should be also localized
2009-02-07T18:08:15+00:00
17393
Repository
José Valim
Joshua Peek
http://rails.lighthouseapp.com/projects/8994/tickets/1886
The current implementation of localized templates on rails/actionpack/lib/action_view/paths.rb is incomplete.
At the line 48, when we check for a html file when format is js (this is used in when xhr? is true) should be also localized. So what we have now as:
# Try to find html version if the format is javascript
elsif format == :js && template = load_path["#{template_path}.html"]
return template
end
Should actually be:
# Try to find html version if the format is javascript
elsif format == :js && template = load_path["#{template_path}.#{I18n.locale}.html"]
return template
end
elsif format == :js && template = load_path["#{template_path}.html"]
return template
end
I'm not building a patch, since it's a quick fix.
The current implementation of localized templates on rails/actionpack/lib/action_view/paths.rb is incomplete.
At the line 48, when we check for a html file when format is js (this is used in when xhr? is true) should be also localized. So what we have now as:
# Try to find html version if the format is javascript
elsif format == :js && template = load_path["#{template_path}.html"]
return template
end
Should actually be:
# Try to find html version if the format is javascript
elsif format == :js && template = load_path["#{template_path}.#{I18n.locale}.html"]
return template
end
elsif format == :js && template = load_path["#{template_path}.html"]
return template
end
I'm not building a patch, since it's a quick fix.
<div><p>The current implementation of localized templates on
rails/actionpack/lib/action_view/paths.rb is incomplete.</p>
<p>At the line 48, when we check for a html file when format is js
(this is used in when xhr? is true) should be also localized. So
what we have now as:</p>
<p># Try to find html version if the format is javascript elsif
format == :js && template =
load_path["#{template_path}.html"]</p>
<pre>
<code>return template
</code>
</pre>
<p>end</p>
<p>Should actually be:</p>
<p># Try to find html version if the format is javascript elsif
format == :js && template =
load_path["#{template_path}.#{I18n.locale}.html"]</p>
<pre>
<code>return template
</code>
</pre>
<p>end elsif format == :js && template =
load_path["#{template_path}.html"]</p>
<pre>
<code>return template
</code>
</pre>
<p>end</p>
<p>I'm not building a patch, since it's a quick fix.</p></div>
424
2
true
2009-02-05T18:36:41+00:00
19965
2009-01-31T00:00:00+00:00
1888
localized-templates-does-not-work-with-pt-br-or-en-us-as-locale
55
8994
resolved
Localized templates does not work with "pt-BR" or "en-US" as locale
2009-02-07T05:29:25+00:00
17393
Repository
José Valim
Joshua Peek
http://rails.lighthouseapp.com/projects/8994/tickets/1888
Localized templates is not working when the locale contains a dash "-".
The reason of it is on rails/actionpack/lib/action_view/template.rb.
On line 239 we see the regexp that process our extensions in our view path is
@@@ ruby
m = extensions.match(/^(\w+)?\.?(\w+)?\.?(\w+)?\.?/)
@@@
The first parenthesis, which is the one that checks for the locale does not accepts dash -.
A working regexp would be:
@@@ ruby
/^(\w+\-?\w*)?\.?(\w+)?\.?(\w+)?\.?/
@@@
And we can see it working on Rubular:
http://www.rubular.com/regexes/6077
Localized templates is not working when the locale contains a dash "-".
The reason of it is on rails/actionpack/lib/action_view/template.rb.
On line 239 we see the regexp that process our extensions in our view path is
@@@ ruby
m = extensions.match(/^(\w+)?\.?(\w+)?\.?(\w+)?\.?/)
@@@
The first parenthesis, which is the one that checks for the locale does not accepts dash -.
A working regexp would be:
@@@ ruby
/^(\w+\-?\w*)?\.?(\w+)?\.?(\w+)?\.?/
@@@
And we can see it working on Rubular:
http://www.rubular.com/regexes/6077
<div><p>Localized templates is not working when the locale contains a
dash "-".</p>
<p>The reason of it is on
rails/actionpack/lib/action_view/template.rb.</p>
<p>On line 239 we see the regexp that process our extensions in our
view path is</p>
<pre><code class="ruby">
m = extensions.match(/^(\w+)?\.?(\w+)?\.?(\w+)?\.?/)
</code></pre>
<p>The first parenthesis, which is the one that checks for the
locale does not accepts dash -.</p>
<p>A working regexp would be:</p>
<pre><code class="ruby">
/^(\w+\-?\w*)?\.?(\w+)?\.?(\w+)?\.?/
</code></pre>
<p>And we can see it working on Rubular:</p>
<p><a href="http://www.rubular.com/regexes/6077">http://www.rubular.com/regexes/6077</a></p></div>
424
0
true
2009-02-05T16:50:40+00:00
19965
9903
1884
actionviewbase-_render_stack-is-not-being-filled-on-edge
1115
8994
wontfix
ActionView::Base @_render_stack is not being filled on edge
2009-02-05T22:30:19+00:00
19965
José Valim
José Valim
Joshua Peek
http://rails.lighthouseapp.com/projects/8994/tickets/1884
2.x
I'm the developer of Rails Footnotes plugin and I need to know the location of the template being rendered.
I've put a debugger at the end of process method on ActionController::Base, and then called:
@template.template
Which returned nil, Since the template method give me the last object in the @_render_stack variable, I've checked and I can't actually see where the @_render_stack is being filled. It's always empty.
I'm the developer of Rails Footnotes plugin and I need to know the location of the template being rendered.
I've put a debugger at the end of process method on ActionController::Base, and then called:
@template.template
Which returned nil, Since the template method give me the last object in the @_render_stack variable, I've checked and I can't actually see where the @_render_stack is being filled. It's always empty.
<div><p>I'm the developer of Rails Footnotes plugin and I need to know
the location of the template being rendered.</p>
<p>I've put a debugger at the end of process method on
ActionController::Base, and then called:</p>
<p>@template.template</p>
<p>Which returned nil, Since the template method give me the last
object in the @<em>render_stack variable, I've checked and I can't
actually see where the @</em>render_stack is being filled. It's
always empty.</p></div>
83
1
true
2009-02-01T08:52:14+00:00
19965
9903
1835
add-localized-rescue
941
8994
committed
2.3 actionpack localization
Add Localized Rescue
2009-02-02T16:58:59+00:00
17393
Repository
José Valim
DHH
http://rails.lighthouseapp.com/projects/8994/tickets/1835
2.x
This patch adds Localized Rescue to Rails. This way we can have "public/404.en.html" or "public/404.pt-BR.html". If the localized rescue file can't be found, render the default one "public/404.html".
Discussion here: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/32dafcea780bda1e
This patch adds Localized Rescue to Rails. This way we can have "public/404.en.html" or "public/404.pt-BR.html". If the localized rescue file can't be found, render the default one "public/404.html".
Discussion here: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/32dafcea780bda1e
<div><p>This patch adds Localized Rescue to Rails. This way we can have
"public/404.en.html" or "public/404.pt-BR.html". If the localized
rescue file can't be found, render the default one
"public/404.html".</p>
<p>Discussion here: <a href="http://groups.google.com/group/rubyonrails-core/browse_thread/thread/32dafcea780bda1e">
http://groups.google.com/group/r...</a></p></div>
0
true
2008-07-30T15:46:09+01:00
19965
9903
728
config-load_paths-should-also-be-frozen
193
8994
resolved
bug railties
config.load_paths should also be frozen
2008-10-30T21:28:42+00:00
17393
Repository
José Valim
http://rails.lighthouseapp.com/projects/8994/tickets/728
2.x
On Rails::Initializer, configuration.load_once_paths is frozen but config.load_paths is not.
We need to freeze them so future modifications will fail rather than do nothing mysteriously. For example, I was changing the variable on my environment/development.rb and the path I was setting was never loaded.
To fix, just add the line:
configuration.load_paths.freeze
To railties/lib/initializer.rb, method set_autoload_paths, around line 214.
So we will have:
def set_autoload_paths
Dependencies.load_paths = configuration.load_paths.uniq
Dependencies.load_once_paths = configuration.load_once_paths.uniq
extra = Dependencies.load_once_paths - Dependencies.load_paths
unless extra.empty?
abort <<-end_error
load_once_paths must be a subset of the load_paths.
Extra items in load_once_paths: #{extra * ','}
end_error
end
configuration.load_once_paths.freeze
end
On Rails::Initializer, configuration.load_once_paths is frozen but config.load_paths is not.
We need to freeze them so future modifications will fail rather than do nothing mysteriously. For example, I was changing the variable on my environment/development.rb and the path I was setting was never loaded.
To fix, just add the line:
configuration.load_paths.freeze
To railties/lib/initializer.rb, method set_autoload_paths, around line 214.
So we will have:
def set_autoload_paths
Dependencies.load_paths = configuration.load_paths.uniq
Dependencies.load_once_paths = configuration.load_once_paths.uniq
extra = Dependencies.load_once_paths - Dependencies.load_paths
unless extra.empty?
abort <<-end_error
load_once_paths must be a subset of the load_paths.
Extra items in load_once_paths: #{extra * ','}
end_error
end
configuration.load_once_paths.freeze
end
<div><p>
On Rails::Initializer, configuration.load_once_paths is frozen but config.load_paths is not.
</p><p>
We need to freeze them so future modifications will fail rather than do nothing mysteriously. For example, I was changing the variable on my environment/development.rb and the path I was setting was never loaded.
</p><p>
To fix, just add the line:
</p><p>
configuration.load_paths.freeze
</p><p>
To railties/lib/initializer.rb, method set_autoload_paths, around line 214.
</p><p>
So we will have:
</p><p>
def set_autoload_paths
</p><p>
Dependencies.load_paths = configuration.load_paths.uniq
</p><p>
Dependencies.load_once_paths = configuration.load_once_paths.uniq
</p><p>
extra = Dependencies.load_once_paths - Dependencies.load_paths
</p><p>
unless extra.empty?
</p><p>
abort <</p><p>
load_once_paths must be a subset of the load_paths.
</p><p>
Extra items in load_once_paths: #{extra * ','}
</p><p>
end_error
</p><p>
end
</p><p>
configuration.load_once_paths.freeze
</p><p>
end
</p></div>
1
true
2008-06-14T09:53:33+01:00
19965
416
caches_actions-accepts-cache_store-options-such-as-expires_in
16631
8994
resolved
actionpack patch tested
caches_actions accepts cache_store options such as :expires_in
2008-09-13T20:20:54+01:00
23117
Alex Farrill
José Valim
http://rails.lighthouseapp.com/projects/8994/tickets/416
With this tiny path, we will be able to do:
@@@ ruby
class ProjectsController < ActionController::Base
caches_action :show, :expires_in => 1.hour
end
@@@
This is useful if you are using memcached.
Tests included (just an expectation to check if options are being sent).
With this tiny path, we will be able to do:
@@@ ruby
class ProjectsController < ActionController::Base
caches_action :show, :expires_in => 1.hour
end
@@@
This is useful if you are using memcached.
Tests included (just an expectation to check if options are being sent).
<div><p>
With this tiny path, we will be able to do:
</p>
<pre><code class="ruby"> class ProjectsController < ActionController::Base
caches_action :show, :expires_in => 1.hour
end
</code></pre>
<p>
This is useful if you are using memcached.
</p><p>
Tests included (just an expectation to check if options are being sent).
</p></div>
85
0
true
2008-07-29T20:03:43+01:00
19965
2009-03-18T00:00:00+00:00
9901
722
rails-initializer-should-assure-erb-is-loaded-before-reading-database-yml
11956
8994
resolved
bug railties
Rails::Initializer should assure ERB is loaded before reading database.yml
2008-07-30T10:08:01+01:00
17393
Repository
José Valim
Jeremy Kemper
http://rails.lighthouseapp.com/projects/8994/tickets/722
2.1.1
I was trying to create an environment where only ActiveRecord was loaded, but since ERB is loaded by ActionPack, when reading and interpreting database.yml on initializer.rb, it raises an error.
To fix I just needed to add the line below to railties/lib/initializer.rb, on the database_configuration method (around line 700):
require 'erb' unless defined?(ERB)
So we have:
def database_configuration
require 'erb' unless defined?(ERB)
YAML::load(ERB.new(IO.read(database_configuration_file)).result)
end
I was trying to create an environment where only ActiveRecord was loaded, but since ERB is loaded by ActionPack, when reading and interpreting database.yml on initializer.rb, it raises an error.
To fix I just needed to add the line below to railties/lib/initializer.rb, on the database_configuration method (around line 700):
require 'erb' unless defined?(ERB)
So we have:
def database_configuration
require 'erb' unless defined?(ERB)
YAML::load(ERB.new(IO.read(database_configuration_file)).result)
end
<div><p>
I was trying to create an environment where only ActiveRecord was loaded, but since ERB is loaded by ActionPack, when reading and interpreting database.yml on initializer.rb, it raises an error.
</p><p>
To fix I just needed to add the line below to railties/lib/initializer.rb, on the database_configuration method (around line 700):
</p><p>
require 'erb' unless defined?(ERB)
</p><p>
So we have:
</p><p>
def database_configuration
</p><p>
require 'erb' unless defined?(ERB)
</p><p>
YAML::load(ERB.new(IO.read(database_configuration_file)).result)
</p><p>
end
</p></div>
85
0
true
2008-07-29T19:41:08+01:00
19965
2009-03-18T00:00:00+00:00
9901
721
dispatcher-should-only-be-loaded-if-actioncontroller-is-defined
11955
8994
resolved
bug railties
dispatcher should only be loaded if ActionController is defined
2008-07-30T10:07:58+01:00
17393
Repository
José Valim
Jeremy Kemper
http://rails.lighthouseapp.com/projects/8994/tickets/721
2.1.1
I was trying to create an environment where only ActiveRecord and ActionMailer were loaded but it failed on the last step.
The dispatcher is loaded even if ActionController is not defined. To fix it I just needed to add the line below to railties/lib/initializer.rb, on the prepare_dispatcher method, around line 480:
return unless configuration.frameworks.include?(:action_controller)
So we have:
def prepare_dispatcher
return unless configuration.frameworks.include?(:action_controller)
require 'dispatcher' unless defined?(::Dispatcher)
Dispatcher.define_dispatcher_callbacks(configuration.cache_classes)
Dispatcher.new(RAILS_DEFAULT_LOGGER).send :run_callbacks, :prepare_dispatch
end
I was trying to create an environment where only ActiveRecord and ActionMailer were loaded but it failed on the last step.
The dispatcher is loaded even if ActionController is not defined. To fix it I just needed to add the line below to railties/lib/initializer.rb, on the prepare_dispatcher method, around line 480:
return unless configuration.frameworks.include?(:action_controller)
So we have:
def prepare_dispatcher
return unless configuration.frameworks.include?(:action_controller)
require 'dispatcher' unless defined?(::Dispatcher)
Dispatcher.define_dispatcher_callbacks(configuration.cache_classes)
Dispatcher.new(RAILS_DEFAULT_LOGGER).send :run_callbacks, :prepare_dispatch
end
<div><p>
I was trying to create an environment where only ActiveRecord and ActionMailer were loaded but it failed on the last step.
</p><p>
The dispatcher is loaded even if ActionController is not defined. To fix it I just needed to add the line below to railties/lib/initializer.rb, on the prepare_dispatcher method, around line 480:
</p><p>
return unless configuration.frameworks.include?(:action_controller)
</p><p>
So we have:
</p><p>
def prepare_dispatcher
</p><p>
return unless configuration.frameworks.include?(:action_controller)
</p><p>
require 'dispatcher' unless defined?(::Dispatcher)
</p><p>
Dispatcher.define_dispatcher_callbacks(configuration.cache_classes)
</p><p>
Dispatcher.new(RAILS_DEFAULT_LOGGER).send :run_callbacks, :prepare_dispatch
</p><p>
end
</p></div>
1366
1
true
2008-06-12T13:14:50+01:00
19965
402
request_forgery_protection_token-should-be-set-at-actioncontroller-base-load-time
18280
8994
wontfix
actionpack bug patch request-forgery-protection
request_forgery_protection_token should be set at ActionController::Base load time
2008-07-04T02:09:19+01:00
1366
Pratik
José Valim
Pratik
http://rails.lighthouseapp.com/projects/8994/tickets/402
This is a small-tiny-patch but important one.
I have one controller, that logs-in users:
@@@ ruby
class UsersController < ActionController::Base
protect_from_forgery :only => :login
def login
...
end
end
@@@
And I have another one, that shows my homepage:
@@@ ruby
class ContentController < ActionController::Base
def index
...
end
end
@@@
What happens is that my homepage has a form to login users quickly, but since request_forgery_protection_token is nil when my app loads, protect_against_forgery? returns false and the form doesn't have a authenticity_token field.
So, when the user fill the form, it will be sent to UsersController#login, that will call protect_from_forgery that will finally set request_forgery_protection_token.
But since no token was sent, it will raise a InvalidAutenticityToken error.
To fix this, we just have to set on ActionController::Base:
@@@ ruby
@@request_forgery_protection_token = :authenticity_token
@@@
And while it's not released, I recommend to put the line above in your ApplicationController.
This is a small-tiny-patch but important one.
I have one controller, that logs-in users:
@@@ ruby
class UsersController < ActionController::Base
protect_from_forgery :only => :login
def login
...
end
end
@@@
And I have another one, that shows my homepage:
@@@ ruby
class ContentController < ActionController::Base
def index
...
end
end
@@@
What happens is that my homepage has a form to login users quickly, but since request_forgery_protection_token is nil when my app loads, protect_against_forgery? returns false and the form doesn't have a authenticity_token field.
So, when the user fill the form, it will be sent to UsersController#login, that will call protect_from_forgery that will finally set request_forgery_protection_token.
But since no token was sent, it will raise a InvalidAutenticityToken error.
To fix this, we just have to set on ActionController::Base:
@@@ ruby
@@request_forgery_protection_token = :authenticity_token
@@@
And while it's not released, I recommend to put the line above in your ApplicationController.
<div><p>
This is a small-tiny-patch but important one.
</p><p>
I have one controller, that logs-in users:
</p>
<pre><code class="ruby"> class UsersController < ActionController::Base
protect_from_forgery :only => :login
def login
...
end
end
</code></pre>
<p>
And I have another one, that shows my homepage:
</p>
<pre><code class="ruby"> class ContentController < ActionController::Base
def index
...
end
end
</code></pre>
<p>
What happens is that my homepage has a form to login users quickly, but since request_forgery_protection_token is nil when my app loads, protect_against_forgery? returns false and the form doesn't have a authenticity_token field.
</p><p>
So, when the user fill the form, it will be sent to UsersController#login, that will call protect_from_forgery that will finally set request_forgery_protection_token.
</p><p>
But since no token was sent, it will raise a InvalidAutenticityToken error.
</p><p>
To fix this, we just have to set on ActionController::Base:
</p>
<pre><code class="ruby"> @@request_forgery_protection_token = :authenticity_token
</code></pre>
<p>
And while it's not released, I recommend to put the line above in your ApplicationController.
</p></div>
1366
2
true
2008-06-02T12:26:07+01:00
19965
298
added-more-support-to-actionview-base-erb_variable
17003
8994
invalid
actionpack bug patch
Added more support to ActionView::Base.erb_variable
2008-06-17T18:54:16+01:00
1366
Pratik
José Valim
Pratik
http://rails.lighthouseapp.com/projects/8994/tickets/298
If we change ActionView::Base.erb_variable, cache_fragment doesn't work and some javascript functions also, because they are checking for the existence of '_erbout' instead of the variable set in erb_variable.
It's just a small patch, that fix javascript functions and send erb_variable to Erb.new().
I also added the line below in fragment cache tests setup to assure that they are working with any variable set.
ActionView::Base.erb_variable = '_buf'
If we change ActionView::Base.erb_variable, cache_fragment doesn't work and some javascript functions also, because they are checking for the existence of '_erbout' instead of the variable set in erb_variable.
It's just a small patch, that fix javascript functions and send erb_variable to Erb.new().
I also added the line below in fragment cache tests setup to assure that they are working with any variable set.
ActionView::Base.erb_variable = '_buf'
<div><p>
If we change ActionView::Base.erb_variable, cache_fragment doesn't work and some javascript functions also, because they are checking for the existence of '_erbout' instead of the variable set in erb_variable.
</p><p>
It's just a small patch, that fix javascript functions and send erb_variable to Erb.new().
</p><p>
I also added the line below in fragment cache tests setup to assure that they are working with any variable set.
</p><p>
ActionView::Base.erb_variable = '_buf'
</p></div>
424
1
true
2008-05-14T19:28:27+01:00
19965
9903
198
caches_action-with-layout-option
10
8994
resolved
actionpack patch tested
caches_action with :layout option
2008-06-03T20:04:16+01:00
17393
Repository
José Valim
Joshua Peek
http://rails.lighthouseapp.com/projects/8994/tickets/198
2.x
Added :layout to caches_action method.
If you specify :layout => false, the layout will not be cached, only the action content. This is useful if you have dynamic content in your layout (which is true for most applications).
This is useful to avoid fragment caching in the whole action and is faster also.
If the :layout is not set or set to true, we have the default behavior.
Tests added.
Added :layout to caches_action method.
If you specify :layout => false, the layout will not be cached, only the action content. This is useful if you have dynamic content in your layout (which is true for most applications).
This is useful to avoid fragment caching in the whole action and is faster also.
If the :layout is not set or set to true, we have the default behavior.
Tests added.
<div><p>
Added :layout to caches_action method.
</p><p>
If you specify :layout => false, the layout will not be cached, only the action content. This is useful if you have dynamic content in your layout (which is true for most applications).
</p><p>
This is useful to avoid fragment caching in the whole action and is faster also.
</p><p>
If the :layout is not set or set to true, we have the default behavior.
</p><p>
Tests added.
</p></div>