19965
2
false
2010-02-05T15:50:45+00:00
85386
27004
3864
rails-server-doesnt-start-mongrel-by-default
3
8994
open
bug mongrel patch regression server
"rails server" doesn't start mongrel by default
2010-02-09T17:05:30+00:00
27155
Craig Buchek
Torsten Maul
José Valim
http://rails.lighthouseapp.com/projects/8994/tickets/3864
3.0
My environment: Windows XP, Ruby 1.8.7, Rails 3.0.0.beta, Mongrel gem installed
When issueing the command
@@@
rails server
@@@
in my application path, WEBrick is started, instead of Mongrel. From looking in the documentation, there seems to be no option for setting the server. I tried with
@@@
rails server mongrel
@@@
, but that doesn't work too.
One workaround I've found, is to call
@@@
rackup --server mongrel --port 3000
@@@
in your application path.
My environment: Windows XP, Ruby 1.8.7, Rails 3.0.0.beta, Mongrel gem installed
When issueing the command
@@@
rails server
@@@
in my application path, WEBrick is started, instead of Mongrel. From looking in the documentation, there seems to be no option for setting the server. I tried with
@@@
rails server mongrel
@@@
, but that doesn't work too.
One workaround I've found, is to call
@@@
rackup --server mongrel --port 3000
@@@
in your application path.
<div><p>My environment: Windows XP, Ruby 1.8.7, Rails 3.0.0.beta,
Mongrel gem installed</p>
<p>When issueing the command<br></p>
<pre>
<code>rails server</code>
</pre>
in my application path, WEBrick is started, instead of Mongrel.
From looking in the documentation, there seems to be no option for
setting the server. I tried with
<pre>
<code>rails server mongrel</code>
</pre>
, but that doesn't work too.
<p>One workaround I've found, is to call<br></p>
<pre>
<code>rackup --server mongrel --port 3000</code>
</pre>
in your application path.</div>
12714
4
false
2008-09-01T07:23:05+01:00
18566
27004
948
template-lookup-should-search-controller-inheritance-chain
3
8994
open
actionpack edge enhancement patch
template lookup should search controller inheritance chain
2010-02-09T16:50:09+00:00
72560
artemave
Caio Chassot
Yehuda Katz (wycats)
http://rails.lighthouseapp.com/projects/8994/tickets/948
3.0
(Josh, I briefly mentioned this to you via email.)
Here's the gist of the feature:
Say you have:
DocumentsController < ApplicationController
ArticlesController < DocumentsController
and a view file at:
app/views/documents/list.html.erb
If you request articles/list, and app/views/articles/list.html.erb doesn't exist, rails should render app/views/documents/list.html.erb for you.
Here's my plugin that implements this behavior:
http://github.com/kch/inheritable_templates/tree/master
I'm opening this case to consider making this behavior default in rails.
If you would please experiment with the plugin and let me know if the core is interested, I'd be happy to convert the plugin into a patch.
(Josh, I briefly mentioned this to you via email.)
Here's the gist of the feature:
Say you have:
DocumentsController < ApplicationController
ArticlesController < DocumentsController
and a view file at:
app/views/documents/list.html.erb
If you request articles/list, and app/views/articles/list.html.erb doesn't exist, rails should render app/views/documents/list.html.erb for you.
Here's my plugin that implements this behavior:
http://github.com/kch/inheritable_templates/tree/master
I'm opening this case to consider making this behavior default in rails.
If you would please experiment with the plugin and let me know if the core is interested, I'd be happy to convert the plugin into a patch.
<div><p>(Josh, I briefly mentioned this to you via email.)</p>
<p>Here's the gist of the feature:</p>
<p>Say you have:</p>
<p>DocumentsController < ApplicationController
ArticlesController < DocumentsController</p>
<p>and a view file at:</p>
<p>app/views/documents/list.html.erb</p>
<p>If you request articles/list, and
app/views/articles/list.html.erb doesn't exist, rails should render
app/views/documents/list.html.erb for you.</p>
<p>Here's my plugin that implements this behavior:</p>
<p><a href="http://github.com/kch/inheritable_templates/tree/master">http://github.com/kch/inheritabl...</a></p>
<p>I'm opening this case to consider making this behavior default
in rails.</p>
<p>If you would please experiment with the plugin and let me know
if the core is interested, I'd be happy to convert the plugin into
a patch.</p></div>
19965
1
false
2010-02-06T12:14:54+00:00
9958
27004
3877
eg-rails-server-e-test-doesnt-work-rails_envtest-rails-server-does
2
8994
verified
initialization patch rails3 server
E.g. "rails server -e test" doesn't work, "RAILS_ENV=test rails server" does
2010-02-09T14:04:06+00:00
19965
José Valim
Henrik Nyh
José Valim
http://rails.lighthouseapp.com/projects/8994/tickets/3877
3.0
Looks like "railties/lib/rails/commands/server.rb" successfully sets RAILS_ENV to "test" when doing "rails server -e test", but Rails.env is still set to development:
@@@ bash
henrik@Nyx ~/Sites/rails3test$ rails server -e test
=> Booting WEBrick
=> Rails 3.0.0.beta application starting in development on http://0.0.0.0:3000
@@@
The "starting in development" string uses Rails.env. I also made a controller raise Rails.env and that was "development", too. So it's not just server.rb showing the wrong value.
My guess is that server.rb changes ENV['RAILS_ENV'] too late, after it's already been read for Rails.env.
It works as expected with "RAILS_ENV=test rails server":
@@@ bash
henrik@Nyx ~/Sites/rails3test$ RAILS_ENV=test rails server
=> Booting WEBrick
=> Rails 3.0.0.beta application starting in test on http://0.0.0.0:3000
@@@
All this is on OS X.
I'll see if I can patch it, but I don't have a lot of time to spare right now.
Looks like "railties/lib/rails/commands/server.rb" successfully sets RAILS_ENV to "test" when doing "rails server -e test", but Rails.env is still set to development:
@@@ bash
henrik@Nyx ~/Sites/rails3test$ rails server -e test
=> Booting WEBrick
=> Rails 3.0.0.beta application starting in development on http://0.0.0.0:3000
@@@
The "starting in development" string uses Rails.env. I also made a controller raise Rails.env and that was "development", too. So it's not just server.rb showing the wrong value.
My guess is that server.rb changes ENV['RAILS_ENV'] too late, after it's already been read for Rails.env.
It works as expected with "RAILS_ENV=test rails server":
@@@ bash
henrik@Nyx ~/Sites/rails3test$ RAILS_ENV=test rails server
=> Booting WEBrick
=> Rails 3.0.0.beta application starting in test on http://0.0.0.0:3000
@@@
All this is on OS X.
I'll see if I can patch it, but I don't have a lot of time to spare right now.
<div><p>Looks like "railties/lib/rails/commands/server.rb" successfully
sets RAILS_ENV to "test" when doing "rails server -e test", but
Rails.env is still set to development:</p>
<pre>
<code class=
"bash">henrik@Nyx ~/Sites/rails3test$ rails server -e test
=> Booting WEBrick
=> Rails 3.0.0.beta application starting in development on http://0.0.0.0:3000</code>
</pre>
<p>The "starting in development" string uses Rails.env. I also made
a controller raise Rails.env and that was "development", too. So
it's not just server.rb showing the wrong value.</p>
<p>My guess is that server.rb changes ENV['RAILS_ENV'] too late,
after it's already been read for Rails.env.</p>
<p>It works as expected with "RAILS_ENV=test rails server":</p>
<pre>
<code class=
"bash">henrik@Nyx ~/Sites/rails3test$ RAILS_ENV=test rails server
=> Booting WEBrick
=> Rails 3.0.0.beta application starting in test on http://0.0.0.0:3000</code>
</pre>
<p>All this is on OS X.</p>
<p>I'll see if I can patch it, but I don't have a lot of time to
spare right now.</p></div>
1
false
2010-02-09T07:24:21+00:00
27508
3904
bundle-group-for-addition-of-custom-irb-helpers-to-rails-console
0
8994
new
3.0 console patch
bundle group for addition of custom irb helpers to rails console
2010-02-09T07:24:32+00:00
27508
codesnik
codesnik
http://rails.lighthouseapp.com/projects/8994/tickets/3904
now that rails uses Bundler which loads only gems from Gemfile, your lovely .irbrc just doesn't work anymore with "rails console", if you happen to load some gems there.
There's workaround: you can remove your ~/.irbrc (it has a higher precedence) and create "irbrc" in Rails.root, containing just "Bundler.require :console", then create group in your Gemfile
group :console do
gem "every"
gem "wirble"
...
end
this way you don't load thoose gems in rails server or rake tasks, but have them installed and required even in rails console on production servers, which is quite handy in small setups.
but Bundle.require :console could be added to rails console itself, just before loading IRB, and it won't hurt anybody. And then you can drop irbrc in Rails.root if thoose gems do not require additional configuration or initialization.
now that rails uses Bundler which loads only gems from Gemfile, your lovely .irbrc just doesn't work anymore with "rails console", if you happen to load some gems there.
There's workaround: you can remove your ~/.irbrc (it has a higher precedence) and create "irbrc" in Rails.root, containing just "Bundler.require :console", then create group in your Gemfile
group :console do
gem "every"
gem "wirble"
...
end
this way you don't load thoose gems in rails server or rake tasks, but have them installed and required even in rails console on production servers, which is quite handy in small setups.
but Bundle.require :console could be added to rails console itself, just before loading IRB, and it won't hurt anybody. And then you can drop irbrc in Rails.root if thoose gems do not require additional configuration or initialization.
<div><p>now that rails uses Bundler which loads only gems from Gemfile,
your lovely .irbrc just doesn't work anymore with "rails console",
if you happen to load some gems there.</p>
<p>There's workaround: you can remove your ~/.irbrc (it has a
higher precedence) and create "irbrc" in Rails.root, containing
just "Bundler.require :console", then create group in your
Gemfile</p>
<p>group :console do</p>
<pre>
<code>gem "every"
gem "wirble"
...</code>
</pre>
<p>end</p>
<p>this way you don't load thoose gems in rails server or rake
tasks, but have them installed and required even in rails console
on production servers, which is quite handy in small setups.</p>
<p>but Bundle.require :console could be added to rails console
itself, just before loading IRB, and it won't hurt anybody. And
then you can drop irbrc in Rails.root if thoose gems do not require
additional configuration or initialization.</p></div>
1
false
2010-02-08T20:03:47+00:00
9785
3901
patch-generator-gem-command-doesnt-accept-versions
0
8994
new
bug gem generators patch
[PATCH] Generator 'gem' command doesn't accept versions
2010-02-09T02:54:26+00:00
17051
Adam Bair
Michael Bleigh
http://rails.lighthouseapp.com/projects/8994/tickets/3901
In master, the `gem` command of generators will append to the Gemfile an unescaped version string. For example, with this command:
gem 'rspec', '>=2.0.0.a5'
The Gemfile will look like so at the end:
gem "rspec", >=2.0.0.a5
The attached patch fixes this behavior and adds tests both for the version escaping as well as testing to make sure each gem gets its own line.
In master, the `gem` command of generators will append to the Gemfile an unescaped version string. For example, with this command:
gem 'rspec', '>=2.0.0.a5'
The Gemfile will look like so at the end:
gem "rspec", >=2.0.0.a5
The attached patch fixes this behavior and adds tests both for the version escaping as well as testing to make sure each gem gets its own line.
<div><p>In master, the <code>gem</code> command of generators will
append to the Gemfile an unescaped version string. For example,
with this command:</p>
<pre>
<code>gem 'rspec', '>=2.0.0.a5'</code>
</pre>
<p>The Gemfile will look like so at the end:</p>
<pre>
<code>gem "rspec", >=2.0.0.a5</code>
</pre>
<p>The attached patch fixes this behavior and adds tests both for
the version escaping as well as testing to make sure each gem gets
its own line.</p></div>
1
false
2010-01-03T17:25:20+00:00
17268
3645
let-label-helpers-accept-blocks
0
8994
new
action_view block form_helper form_tag_helper label label_tag patch to_label_tag
Let label helpers accept blocks
2010-02-08T14:56:02+00:00
17268
Stephen Celis
Stephen Celis
http://rails.lighthouseapp.com/projects/8994/tickets/3645
Label helpers should process blocks in addition to their defaults because it's common for their content to have more complex markup than text.
This, for example,
@@@
<%= f.label :terms, "<span>Accept #{link_to 'Terms', terms_path}</span>" %>
@@@
Is much easier to read in a block
@@@
<% f.label :terms do %>
<span>Accept <%= link_to "Terms", terms_path %></span>
<% end %>
@@@
An additional perk: in our editors, the HTML markup won't be lost in Ruby string syntax highlighting.
Patch with tests in comments.
Label helpers should process blocks in addition to their defaults because it's common for their content to have more complex markup than text.
This, for example,
@@@
<%= f.label :terms, "<span>Accept #{link_to 'Terms', terms_path}</span>" %>
@@@
Is much easier to read in a block
@@@
<% f.label :terms do %>
<span>Accept <%= link_to "Terms", terms_path %></span>
<% end %>
@@@
An additional perk: in our editors, the HTML markup won't be lost in Ruby string syntax highlighting.
Patch with tests in comments.
<div><p>Label helpers should process blocks in addition to their
defaults because it's common for their content to have more complex
markup than text.</p>
<p>This, for example,<br></p>
<pre>
<code><%= f.label :terms, "<span>Accept #{link_to 'Terms', terms_path}</span>" %></code>
</pre>
<p>Is much easier to read in a block<br></p>
<pre>
<code><% f.label :terms do %>
<span>Accept <%= link_to "Terms", terms_path %></span>
<% end %></code>
</pre>
<p>An additional perk: in our editors, the HTML markup won't be
lost in Ruby string syntax highlighting.</p>
<p>Patch with tests in comments.</p></div>
1
false
2010-02-08T11:46:52+00:00
85635
3899
patch-postgresql-cast-problem-on-defaultvalues
0
8994
new
activerecord fix patch patched postgres postgresql schema
[PATCH] PostgreSQL CAST Problem on Defaultvalues
2010-02-08T11:46:57+00:00
85635
Traxanos
Traxanos
http://rails.lighthouseapp.com/projects/8994/tickets/3899
Hi
i have a problem with PostgreSQL. PostgreSQL can cast default values and AR read the default string with cast into schema.rb.
sample:
<code>
CREATE TABLE soeintest
(
test character varying NOT NULL DEFAULT '456'
);
</code>
on db:
<code>
CREATE TABLE soeintest
(
test character varying NOT NULL DEFAULT '456'::character varying
);
</code>
in schema:
<code>
t.string "test", :default => "'456'::character varying", :null => false
</code>
I have fix this Problem by change the SQL that read the data.
Hi
i have a problem with PostgreSQL. PostgreSQL can cast default values and AR read the default string with cast into schema.rb.
sample:
<code>
CREATE TABLE soeintest
(
test character varying NOT NULL DEFAULT '456'
);
</code>
on db:
<code>
CREATE TABLE soeintest
(
test character varying NOT NULL DEFAULT '456'::character varying
);
</code>
in schema:
<code>
t.string "test", :default => "'456'::character varying", :null => false
</code>
I have fix this Problem by change the SQL that read the data.
<div><p>Hi</p>
<p>i have a problem with PostgreSQL. PostgreSQL can cast default
values and AR read the default string with cast into schema.rb.</p>
<p>sample:<br>
<code><br>
CREATE TABLE soeintest<br>
( test character varying NOT NULL DEFAULT '456' );</code><br>
on db:<br>
<code><br>
CREATE TABLE soeintest<br>
( test character varying NOT NULL DEFAULT '456'::character varying
);</code><br>
in schema:<br>
<code><br>
t.string "test", :default => "'456'::character varying", :null
=> false<br></code><br>
I have fix this Problem by change the SQL that read the data.</p></div>
141
1
false
2009-11-29T14:16:37+00:00
14798
27004
3518
link_to-doesnt-escape-its-input
11
8994
new
patch xss
Link_to doesn't escape its input
2010-02-08T05:58:47+00:00
38796
trevor
Bruno Michel
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/3518
3.0
Hi,
The link_to helper doesn't escape its first argument.
Ryan Bates has made a bug report on github for the Rails-XSS plugin (http://github.com/NZKoz/rails_xss/issues#issue/1), but I think that this problem should be fixed in Rails itself. I've attached a patch to this ticket.
Hi,
The link_to helper doesn't escape its first argument.
Ryan Bates has made a bug report on github for the Rails-XSS plugin (http://github.com/NZKoz/rails_xss/issues#issue/1), but I think that this problem should be fixed in Rails itself. I've attached a patch to this ticket.
<div><p>Hi,</p>
<p>The link_to helper doesn't escape its first argument.</p>
<p>Ryan Bates has made a bug report on github for the Rails-XSS
plugin (<a href=
"http://github.com/NZKoz/rails_xss/issues#issue/1)">http://github.com/NZKoz/rails_xss/issues#issue/1)</a>,
but I think that this problem should be fixed in Rails itself. I've
attached a patch to this ticket.</p></div>
1
false
2010-02-07T19:08:30+00:00
27133
3886
redundant-actionmailer-test-code-supposedly-added-to-fix-a-very-old-mocha-bug
0
8994
new
patch
Redundant ActionMailer test code supposedly added to fix a very old Mocha bug
2010-02-07T19:08:38+00:00
27133
James Mead
James Mead
http://rails.lighthouseapp.com/projects/8994/tickets/3886
In commit 704f2cc6dee9d55d19bfad8e4a8308fdee71bf6f a couple of lines of code were adding with the following comment: "Replacing logger work around for mocha bug. Should be fixed in mocha 0.3.3".
Since the Rails Gemfile now specifies Mocha >= 0.9.8 and since the ActionMailer tests still pass when these lines are removed, it seems sensible to remove them.
In commit 704f2cc6dee9d55d19bfad8e4a8308fdee71bf6f a couple of lines of code were adding with the following comment: "Replacing logger work around for mocha bug. Should be fixed in mocha 0.3.3".
Since the Rails Gemfile now specifies Mocha >= 0.9.8 and since the ActionMailer tests still pass when these lines are removed, it seems sensible to remove them.
<div><p>In commit 704f2cc6dee9d55d19bfad8e4a8308fdee71bf6f a couple of
lines of code were adding with the following comment: "Replacing
logger work around for mocha bug. Should be fixed in mocha
0.3.3".</p>
<p>Since the Rails Gemfile now specifies Mocha >= 0.9.8 and
since the ActionMailer tests still pass when these lines are
removed, it seems sensible to remove them.</p></div>
12714
1
false
2010-02-06T22:31:20+00:00
14798
3883
content_tag-does-not-escape-its-input
0
8994
new
3.0pre patch xss
Content_tag does not escape its input!
2010-02-06T23:47:45+00:00
14798
Bruno Michel
Bruno Michel
Yehuda Katz (wycats)
http://rails.lighthouseapp.com/projects/8994/tickets/3883
Hi,
I've read http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/ and I've tried the example. Obviously, `tag` has to be remplaced by `content_tag` (error 500 else). But, the output is not the expected one, evil_js can be executed:
@@@ html
Hello <strong>friends</strong>!
<p><script>evil_js</script></p>
<script>evil_js</script>
@@@
I've tried to fix content_tag_string like this:
@@@ ruby
def content_tag_string(name, content, options, escape = true)
tag_options = tag_options(options, escape) if options
"<#{name}#{tag_options}>#{ERB::Util.h content}</#{name}>".html_safe
end
@@@
But this breaks a lot of unit tests (184 failures in actionpack). So, I wonder if `content_tag` is really a public API that should escape its input, or if it's only for internal usage.
In the first case, it will also fix 2 others of my tickets: https://rails.lighthouseapp.com/projects/8994/tickets/3450-field_set_tag-doesnt-escape-the-legend and https://rails.lighthouseapp.com/projects/8994/tickets/3449-label-tag-doesnt-escape-its-input.
Hi,
I've read http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/ and I've tried the example. Obviously, `tag` has to be remplaced by `content_tag` (error 500 else). But, the output is not the expected one, evil_js can be executed:
@@@ html
Hello <strong>friends</strong>!
<p><script>evil_js</script></p>
<script>evil_js</script>
@@@
I've tried to fix content_tag_string like this:
@@@ ruby
def content_tag_string(name, content, options, escape = true)
tag_options = tag_options(options, escape) if options
"<#{name}#{tag_options}>#{ERB::Util.h content}</#{name}>".html_safe
end
@@@
But this breaks a lot of unit tests (184 failures in actionpack). So, I wonder if `content_tag` is really a public API that should escape its input, or if it's only for internal usage.
In the first case, it will also fix 2 others of my tickets: https://rails.lighthouseapp.com/projects/8994/tickets/3450-field_set_tag-doesnt-escape-the-legend and https://rails.lighthouseapp.com/projects/8994/tickets/3449-label-tag-doesnt-escape-its-input.
<div><p>Hi,</p>
<p>I've read <a href=
"http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/">http://yehudakatz.com/2010/02/01/safebuffers-and-rails-3-0/</a>
and I've tried the example. Obviously, <code>tag</code> has to be
remplaced by <code>content_tag</code> (error 500 else). But, the
output is not the expected one, evil_js can be executed:</p>
<pre>
<code class="html">Hello <strong>friends</strong>!
<p><script>evil_js</script></p>
&lt;script&gt;evil_js&lt;/script&gt;</code>
</pre>
<p>I've tried to fix content_tag_string like this:<br></p>
<pre>
<code class=
"ruby"> def content_tag_string(name, content, options, escape = true)<br>
<br>
</code>
</pre>
<pre>
<code class=
"ruby"><code> tag_options = tag_options(options, escape) if options
&quot;&lt;#{name}#{tag_options}&gt;#{ERB::Util.h content}&lt;/#{name}&gt;&quot;.html_safe
end </code></code></code>
</pre>
<pre>
<br>
</pre>
But this breaks a lot of unit tests (184 failures in actionpack).
So, I wonder if <code>content_tag</code> is really a public API
that should escape its input, or if it's only for internal usage.
<p>In the first case, it will also fix 2 others of my tickets:
<a href=
"https://rails.lighthouseapp.com/projects/8994/tickets/3450-field_set_tag-doesnt-escape-the-legend">
https://rails.lighthouseapp.com/projects/8994/tickets/3450-field_se...</a>
and <a href=
"https://rails.lighthouseapp.com/projects/8994/tickets/3449-label-tag-doesnt-escape-its-input">
https://rails.lighthouseapp.com/projects/8994/tickets/3449-label-ta...</a>.</p></div>
6601
2
false
2010-02-06T19:10:33+00:00
26790
3881
patch-rails-dev-and-edge-should-bundle-install-to-vendor-not-home-or-system-gems
0
8994
new
bundle patch rails vendor
[PATCH] Rails --dev and --edge should bundle install to vendor, not home or system gems
2010-02-06T20:04:36+00:00
26790
Kieran P
Kieran P
Carl Lerche
http://rails.lighthouseapp.com/projects/8994/tickets/3881
Rails --dev and --edge should bundle install to vendor, not home or system gems.
This prevents altering system gems with possible buggy versions during testing of Rails edge.
Server still starts up perfectly fine with this change, and tests are passing.
Rails --dev and --edge should bundle install to vendor, not home or system gems.
This prevents altering system gems with possible buggy versions during testing of Rails edge.
Server still starts up perfectly fine with this change, and tests are passing.
<div><p>Rails --dev and --edge should bundle install to vendor, not home
or system gems.</p>
<p>This prevents altering system gems with possible buggy versions
during testing of Rails edge.</p>
<p>Server still starts up perfectly fine with this change, and
tests are passing.</p></div>
3890
1
false
2010-01-19T02:17:48+00:00
15459
27004
3743
scriptplugin-install-gitwhatever-does-nothing
2
8994
incomplete
2.3.5 3.0pre bug patch plugin scriptplugin
script/plugin install git://whatever does nothing
2010-02-06T15:54:19+00:00
25293
Prem Sichanugrist (sikachu)
Nate Wiger
Matt Aimonetti (mattetti)
http://rails.lighthouseapp.com/projects/8994/tickets/3743
3.0
Been this way for a while. Borked in 2.3 and 3.0pre. Either script/plugin should be removed or it should really be fixed :-(
[nwiger@sliver:testapp]$ script/plugin install git://github.com/fesplugas/typus.git
Initialized empty Git repository in /Users/nwiger/Workspace/testapp/vendor/plugins/typus/.git/
[nwiger@sliver:testapp]$ ll vendor/plugins/
total 0
drwxr-xr-x 3 nwiger staff 102 Jan 18 08:09 .
drwxr-xr-x 4 nwiger staff 136 Jan 18 08:08 ..
-rw-r--r-- 1 nwiger staff 0 Jan 18 08:08 .gitkeep
Been this way for a while. Borked in 2.3 and 3.0pre. Either script/plugin should be removed or it should really be fixed :-(
[nwiger@sliver:testapp]$ script/plugin install git://github.com/fesplugas/typus.git
Initialized empty Git repository in /Users/nwiger/Workspace/testapp/vendor/plugins/typus/.git/
[nwiger@sliver:testapp]$ ll vendor/plugins/
total 0
drwxr-xr-x 3 nwiger staff 102 Jan 18 08:09 .
drwxr-xr-x 4 nwiger staff 136 Jan 18 08:08 ..
-rw-r--r-- 1 nwiger staff 0 Jan 18 08:08 .gitkeep
<div><p>Been this way for a while. Borked in 2.3 and 3.0pre. Either
script/plugin should be removed or it should really be fixed
:-(</p>
<pre>
<code>[nwiger@sliver:testapp]$ script/plugin install git://github.com/fesplugas/typus.git
Initialized empty Git repository in /Users/nwiger/Workspace/testapp/vendor/plugins/typus/.git/
[nwiger@sliver:testapp]$ ll vendor/plugins/
total 0
drwxr-xr-x 3 nwiger staff 102 Jan 18 08:09 .
drwxr-xr-x 4 nwiger staff 136 Jan 18 08:08 ..
-rw-r--r-- 1 nwiger staff 0 Jan 18 08:08 .gitkeep</code>
</pre></div>
1
false
2009-09-08T23:54:57+01:00
47360
3169
attributes-are-not-serialized-in-sti-subclasses-in-production-mode
139737
8994
new
2-3-stable 2.3.4 activerecord patch serialize sti
Attributes are not serialized in STI subclasses in production mode.
2010-02-05T03:26:04+00:00
85332
Mike Aleksiuk
Zack Hobson
http://rails.lighthouseapp.com/projects/8994/tickets/3169
This was originally reported and patched by Les Hill: https://rails.lighthouseapp.com/projects/8994/tickets/204
The included patch applies to v2.3.4 and fixes this issue for me, but the ticket is stale. I'm regenerating the patch and opening a new ticket in the hopes that this can be fixed in 2.3.x.
This is from his original bug report:
When using STI, if a subclass specifies that an attribute is to be serialized, and that attribute was not specified as serialized in the base class, serialization of the attribute fails.
This bug will only occur in production, not in development mode due to the class reloading in development mode.
class Droid < ActiveRecord::Base
end
class R2D2 < Droid
serialize :secret_message
end
If the R2D2 class is loaded in production after the Droid class is loaded, then the serialization of the secret_message attribute will fail.
This was originally reported and patched by Les Hill: https://rails.lighthouseapp.com/projects/8994/tickets/204
The included patch applies to v2.3.4 and fixes this issue for me, but the ticket is stale. I'm regenerating the patch and opening a new ticket in the hopes that this can be fixed in 2.3.x.
This is from his original bug report:
When using STI, if a subclass specifies that an attribute is to be serialized, and that attribute was not specified as serialized in the base class, serialization of the attribute fails.
This bug will only occur in production, not in development mode due to the class reloading in development mode.
class Droid < ActiveRecord::Base
end
class R2D2 < Droid
serialize :secret_message
end
If the R2D2 class is loaded in production after the Droid class is loaded, then the serialization of the secret_message attribute will fail.
<div><p>This was originally reported and patched by Les Hill: <a href=
"https://rails.lighthouseapp.com/projects/8994/tickets/204">https://rails.lighthouseapp.com/projects/8994/tickets/204</a></p>
<p>The included patch applies to v2.3.4 and fixes this issue for
me, but the ticket is stale. I'm regenerating the patch and opening
a new ticket in the hopes that this can be fixed in 2.3.x.</p>
<p>This is from his original bug report:</p>
<p>When using STI, if a subclass specifies that an attribute is to
be serialized, and that attribute was not specified as serialized
in the base class, serialization of the attribute fails.</p>
<p>This bug will only occur in production, not in development mode
due to the class reloading in development mode.</p>
<p>class Droid < ActiveRecord::Base end</p>
<p>class R2D2 < Droid serialize :secret_message end</p>
<p>If the R2D2 class is loaded in production after the Droid class
is loaded, then the serialization of the secret_message attribute
will fail.</p></div>
2
false
2010-01-24T02:09:06+00:00
8163
3776
layout-lookup-fails-when-a-template-has-locale-in-its-filename
0
8994
new
action_view bug i18n layouts locale patch rails3
Layout lookup fails when a template has locale in its filename
2010-02-04T14:53:45+00:00
8163
Eugene Pimenov
Eugene Pimenov
http://rails.lighthouseapp.com/projects/8994/tickets/3776
In Rails3 I get an error when trying to render a template with locale in its filename.
The repro code is (copied from the attached test):
class WithLocaleInTemplate < Base
layout "hello"
def index
render 'hello_world'
end
end
hello_world, for example, is hello_world.en.html.erb
Exception I get:
NoMethodError: You specified nil as the layout, but no such method was found
rails/actionpack/lib/abstract_controller/layouts.rb:397:in `_default_layout'
Actual exception is
undefined method `|' for :en:Symbol
rails/actionpack/lib/action_view/template/resolver.rb:15:in `register_detail'
rails/actionpack/lib/action_view/template/resolver.rb:59:in `call'
rails/actionpack/lib/action_view/template/resolver.rb:59:in `normalize_detail'
but it's hidden behind rescue NoMethodError in _default_layout.
The fix is one-liner:
- locale = details.last && details.pop.to_sym
+ locale = details.last && [details.pop.to_sym]
In Rails3 I get an error when trying to render a template with locale in its filename.
The repro code is (copied from the attached test):
class WithLocaleInTemplate < Base
layout "hello"
def index
render 'hello_world'
end
end
hello_world, for example, is hello_world.en.html.erb
Exception I get:
NoMethodError: You specified nil as the layout, but no such method was found
rails/actionpack/lib/abstract_controller/layouts.rb:397:in `_default_layout'
Actual exception is
undefined method `|' for :en:Symbol
rails/actionpack/lib/action_view/template/resolver.rb:15:in `register_detail'
rails/actionpack/lib/action_view/template/resolver.rb:59:in `call'
rails/actionpack/lib/action_view/template/resolver.rb:59:in `normalize_detail'
but it's hidden behind rescue NoMethodError in _default_layout.
The fix is one-liner:
- locale = details.last && details.pop.to_sym
+ locale = details.last && [details.pop.to_sym]
<div><p>In Rails3 I get an error when trying to render a template with
locale in its filename.</p>
<p>The repro code is (copied from the attached test):<br></p>
<pre>
<code>class WithLocaleInTemplate < Base
layout "hello"
def index
render 'hello_world'
end
end</code>
</pre>
<p>hello_world, for example, is hello_world.en.html.erb</p>
<p>Exception I get:<br></p>
<pre>
<code> NoMethodError: You specified nil as the layout, but no such method was found
rails/actionpack/lib/abstract_controller/layouts.rb:397:in `_default_layout'</code>
</pre>
<p>Actual exception is</p>
<pre>
<code> undefined method `|' for :en:Symbol
rails/actionpack/lib/action_view/template/resolver.rb:15:in `register_detail'
rails/actionpack/lib/action_view/template/resolver.rb:59:in `call'
rails/actionpack/lib/action_view/template/resolver.rb:59:in `normalize_detail'</code>
</pre>
<p>but it's hidden behind rescue NoMethodError in
_default_layout.</p>
<p>The fix is one-liner:<br></p>
<pre>
<code> - locale = details.last && details.pop.to_sym
+ locale = details.last && [details.pop.to_sym]</code>
</pre></div>
141
1
false
2010-02-03T17:22:44+00:00
12871
3842
overwrite-type-attribute-for-text_field-patch
0
8994
new
email helper patch text_field url
Overwrite type attribute for text_field [PATCH]
2010-02-03T17:22:47+00:00
12871
Yves Vogl
Yves Vogl
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/3842
Hi,
I added the ability to overwrite the type attribute of the text_field helper to e.g. allow creating input fields with type "email" and "url". I decided not to separate those like the ones for "hidden", "password" because it seems that this attributes aren't W3C standard, yet. I added them because they ease the pain on iPhone when entering such information.
Hi,
I added the ability to overwrite the type attribute of the text_field helper to e.g. allow creating input fields with type "email" and "url". I decided not to separate those like the ones for "hidden", "password" because it seems that this attributes aren't W3C standard, yet. I added them because they ease the pain on iPhone when entering such information.
<div><p>Hi,</p>
<p>I added the ability to overwrite the type attribute of the
text_field helper to e.g. allow creating input fields with type
"email" and "url". I decided not to separate those like the ones
for "hidden", "password" because it seems that this attributes
aren't W3C standard, yet. I added them because they ease the pain
on iPhone when entering such information.</p></div>
1
false
2010-02-02T22:00:35+00:00
34876
3839
when-specifying-public-cache-control-also-specify-max-age
0
8994
new
2.3.x actionpack action_pack caching patch
When specifying public Cache-Control, also specify max-age
2010-02-03T16:53:32+00:00
34876
Bill Kirtley
Bill Kirtley
http://rails.lighthouseapp.com/projects/8994/tickets/3839
The ActionController stale? and fresh_when functions will take a :public option, which will cause emission of a Cache-Control header with a public attribute.
Proxy caches will likely interpret a "Cache-Control: public" header to mean that the resource will never change, and will cache it forever.
If you're using either stale? or fresh_when, it's probably because the controlled resource does change over time, so you want to specify a max-age directive in the Cache-Control header to tell the proxy cache how long to serve the resource before asking the origin if it's changed.
Use of expires_in does set the max-age, and it is a workaround for this problem, but it feels awkward to have to do both.
Adding a :max_age option to fresh_when would deal with this nicely
The ActionController stale? and fresh_when functions will take a :public option, which will cause emission of a Cache-Control header with a public attribute.
Proxy caches will likely interpret a "Cache-Control: public" header to mean that the resource will never change, and will cache it forever.
If you're using either stale? or fresh_when, it's probably because the controlled resource does change over time, so you want to specify a max-age directive in the Cache-Control header to tell the proxy cache how long to serve the resource before asking the origin if it's changed.
Use of expires_in does set the max-age, and it is a workaround for this problem, but it feels awkward to have to do both.
Adding a :max_age option to fresh_when would deal with this nicely
<div><p>The ActionController stale? and fresh_when functions will take a
:public option, which will cause emission of a Cache-Control header
with a public attribute.</p>
<p>Proxy caches will likely interpret a "Cache-Control: public"
header to mean that the resource will never change, and will cache
it forever.</p>
<p>If you're using either stale? or fresh_when, it's probably
because the controlled resource does change over time, so you want
to specify a max-age directive in the Cache-Control header to tell
the proxy cache how long to serve the resource before asking the
origin if it's changed.</p>
<p>Use of expires_in does set the max-age, and it is a workaround
for this problem, but it feels awkward to have to do both.</p>
<p>Adding a :max_age option to fresh_when would deal with this
nicely</p></div>
1
false
2010-02-03T01:44:28+00:00
26790
3840
patch-removing-some-test-warnings
0
8994
new
patch tests warnings
[PATCH] Removing some test warnings
2010-02-03T01:44:33+00:00
26790
Kieran P
Kieran P
http://rails.lighthouseapp.com/projects/8994/tickets/3840
Fixed some stuff to remove test warnings in active model and active support test suites. Still quite a few 'overrode method' warnings showing up (esp in ActionMailer). Not sure how to approach these.
Fixed some stuff to remove test warnings in active model and active support test suites. Still quite a few 'overrode method' warnings showing up (esp in ActionMailer). Not sure how to approach these.
<div><p>Fixed some stuff to remove test warnings in active model and
active support test suites. Still quite a few 'overrode method'
warnings showing up (esp in ActionMailer). Not sure how to approach
these.</p></div>
85
7
false
2008-08-06T16:40:48+01:00
28204
2010-01-15T00:00:00+00:00
50064
765
primary_key-option-for-belongs_to
2
8994
incomplete
activerecord belongs_to patch primary_key tests
PATCH: primary_key option for belongs_to
2010-02-02T23:31:19+00:00
19734
Andrew Selder
Shawn
Jeremy Kemper
http://rails.lighthouseapp.com/projects/8994/tickets/765
2.3.6
Could some one add :primary_key option into belongs_to in a similar fashion like ticket 292? This option is a nice-to-have for has_many, because you can always use finder_sql to workaround it. But it is a must-to-have for belongs_to because there is no way to wrok around it. I had a quick look at the source code and added
def owner_quoted_id
if @reflection.options:primary_key]
quote_value(@owner.send @reflection.options:primary_key]))
else
@owner.quoted_id
end
end
into belongs_to.rb.
it didn't work
Could some one add :primary_key option into belongs_to in a similar fashion like ticket 292? This option is a nice-to-have for has_many, because you can always use finder_sql to workaround it. But it is a must-to-have for belongs_to because there is no way to wrok around it. I had a quick look at the source code and added
def owner_quoted_id
if @reflection.options:primary_key]
quote_value(@owner.send @reflection.options:primary_key]))
else
@owner.quoted_id
end
end
into belongs_to.rb.
it didn't work
<div><p>
Could some one add :primary_key option into belongs_to in a similar fashion like ticket 292? This option is a nice-to-have for has_many, because you can always use finder_sql to workaround it. But it is a must-to-have for belongs_to because there is no way to wrok around it. I had a quick look at the source code and added
</p><p>
def owner_quoted_id
</p><p>
if @reflection.options:primary_key]
</p><p>
quote_value(@owner.send @reflection.options:primary_key]))
</p><p>
else
</p><p>
@owner.quoted_id
</p><p>
end
</p><p>
end
</p><p>
into belongs_to.rb.
</p><p>
it didn't work
</p></div>
1366
3
false
2009-03-13T09:56:21+00:00
50150
9903
2227
batches-conditions-for-each-are-applied-to-each-modelfind-within-the-each-loop
1418
8994
new
2-3-stable 2.3-rc1 2.3-rc2 :conditions active_record find named_scope patch
[VERIFIED] batches: :conditions for each are applied to each Model.find within the each loop
2010-02-01T20:12:39+00:00
57403
Brian Armstrong
claudiob (at gmail)
Pratik
http://rails.lighthouseapp.com/projects/8994/tickets/2227
2.x
Consider the following code:
@@@ ruby
# app/models/song.rb
class Song < ActiveRecord::Base
def self.print_pairs(name)
Song.each(:conditions => ['name = ?', name]) do |song|
puts song[:name]
another_song = Song.first(:conditions => ['name <> ?', name])
puts another_song[:name]
end
end
end
@@@
I would call it by passing a song name, and it would print out the name of the same song, and the name of another song (with a different name).
After applying patch #2201, the .each function has become .find_each
The problem that I have found is that the :conditions applied to Song.each (line 4) is also automatically applied to the Song.first (line 6), and as a consequence Song.first returns an error, since it cannot find a song that matches both conditions ['name = ?', name] and ['name <> ?', name].
I understand that the solution to this problem is to call the inside find as following (line 6):
@@@ ruby
another_song = Song.with_exclusive_scope { first(:conditions => ['name <> ?', name]) }
@@@
However it is not clear whether this is a desired behavior or rather a bug.
In this case I have not defined any default_scope for the model Song that has to be overridden by calling with_exclusive_scope, I am just calling Song.find within a Song.each(:conditions) loop.
---
To replicate this behavior:
@@@ sh
rails music
cd music
script/generate scaffold song name:string
rake db:create
rake db:migrate
script/console
@@@
@@@ ruby
Song.create(:name => "Keep The Faith")
Song.create(:name => "Bed Of Roses")
class Song < ActiveRecord::Base
def self.print_pairs(name)
Song.each(:conditions => ['name = ?', name]) do |song|
puts song[:name]
another_song = Song.with_exclusive_scope { first(:conditions => ['name <> ?', name]) }
puts another_song[:name]
end
end
end
Song.print_pairs('Bed Of Roses')
@@@
Once again, the same occurs also after patch #2201, calling .find_each rather than .each, and also using a named_scope to declare the conditions.
Consider the following code:
@@@ ruby
# app/models/song.rb
class Song < ActiveRecord::Base
def self.print_pairs(name)
Song.each(:conditions => ['name = ?', name]) do |song|
puts song[:name]
another_song = Song.first(:conditions => ['name <> ?', name])
puts another_song[:name]
end
end
end
@@@
I would call it by passing a song name, and it would print out the name of the same song, and the name of another song (with a different name).
After applying patch #2201, the .each function has become .find_each
The problem that I have found is that the :conditions applied to Song.each (line 4) is also automatically applied to the Song.first (line 6), and as a consequence Song.first returns an error, since it cannot find a song that matches both conditions ['name = ?', name] and ['name <> ?', name].
I understand that the solution to this problem is to call the inside find as following (line 6):
@@@ ruby
another_song = Song.with_exclusive_scope { first(:conditions => ['name <> ?', name]) }
@@@
However it is not clear whether this is a desired behavior or rather a bug.
In this case I have not defined any default_scope for the model Song that has to be overridden by calling with_exclusive_scope, I am just calling Song.find within a Song.each(:conditions) loop.
---
To replicate this behavior:
@@@ sh
rails music
cd music
script/generate scaffold song name:string
rake db:create
rake db:migrate
script/console
@@@
@@@ ruby
Song.create(:name => "Keep The Faith")
Song.create(:name => "Bed Of Roses")
class Song < ActiveRecord::Base
def self.print_pairs(name)
Song.each(:conditions => ['name = ?', name]) do |song|
puts song[:name]
another_song = Song.with_exclusive_scope { first(:conditions => ['name <> ?', name]) }
puts another_song[:name]
end
end
end
Song.print_pairs('Bed Of Roses')
@@@
Once again, the same occurs also after patch #2201, calling .find_each rather than .each, and also using a named_scope to declare the conditions.
<div><p>Consider the following code:</p>
<pre><code class="ruby">
# app/models/song.rb
class Song < ActiveRecord::Base
def self.print_pairs(name)
Song.each(:conditions => ['name = ?', name]) do |song|
puts song[:name]
another_song = Song.first(:conditions => ['name <> ?', name])
puts another_song[:name]
end
end
end
</code></pre>
<p>I would call it by passing a song name, and it would print out
the name of the same song, and the name of another song (with a
different name). After applying patch <a href="/projects/8994/tickets/2201" title="Ticket #2201">#2201</a>, the
.each function has become .find_each</p>
<p>The problem that I have found is that the :conditions applied to
Song.each (line 4) is also automatically applied to the Song.first
(line 6), and as a consequence Song.first returns an error, since
it cannot find a song that matches both conditions ['name = ?',
name] and ['name <> ?', name].</p>
<p>I understand that the solution to this problem is to call the
inside find as following (line 6):</p>
<pre><code class="ruby">
another_song = Song.with_exclusive_scope { first(:conditions => ['name <> ?', name]) }
</code></pre>
<p>However it is not clear whether this is a desired behavior or
rather a bug. In this case I have not defined any default_scope for
the model Song that has to be overridden by calling
with_exclusive_scope, I am just calling Song.find within a
Song.each(:conditions) loop.</p>
<hr>
<p>To replicate this behavior:</p>
<pre><code class="sh">
rails music
cd music
script/generate scaffold song name:string
rake db:create
rake db:migrate
script/console
</code></pre>
<pre><code class="ruby">
Song.create(:name => "Keep The Faith")
Song.create(:name => "Bed Of Roses")
class Song < ActiveRecord::Base
def self.print_pairs(name)
Song.each(:conditions => ['name = ?', name]) do |song|
puts song[:name]
another_song = Song.with_exclusive_scope { first(:conditions => ['name <> ?', name]) }
puts another_song[:name]
end
end
end
Song.print_pairs('Bed Of Roses')
</code></pre>
<p>Once again, the same occurs also after patch <a href="/projects/8994/tickets/2201" title="Ticket #2201">#2201</a>,
calling .find_each rather than .each, and also using a named_scope
to declare the conditions.</p></div>
85
2
false
2009-02-14T03:37:27+00:00
47398
2010-01-15T00:00:00+00:00
50064
1966
patch-destroy-should-respect-optimistic-locking
5
8994
open
lock patch
Destroy should respect optimistic locking
2010-02-01T12:31:09+00:00
47398
Curtis Hawthorne
Curtis Hawthorne
Jeremy Kemper
http://rails.lighthouseapp.com/projects/8994/tickets/1966
2.3.6
Optimistic locking doesn't currently affect #destroy
calls. This is causing me problems because my after_destroy handlers can end up using stale data. I could also see it causing trouble if a model had some sort of 'do_not_delete' flag that was changed right after AR loaded the record.
So, it seems to me that #destroy should follow the same optimistic locking logic as updates do. That is, add the current lock version to the WHERE clause and raise a StaleObjectError if the delete fails.
I've written a patch (with a test and updated documentation) that accomplishes this.
Optimistic locking doesn't currently affect #destroy
calls. This is causing me problems because my after_destroy handlers can end up using stale data. I could also see it causing trouble if a model had some sort of 'do_not_delete' flag that was changed right after AR loaded the record.
So, it seems to me that #destroy should follow the same optimistic locking logic as updates do. That is, add the current lock version to the WHERE clause and raise a StaleObjectError if the delete fails.
I've written a patch (with a test and updated documentation) that accomplishes this.
<div><p>Optimistic locking doesn't currently affect #destroy calls. This
is causing me problems because my after_destroy handlers can end up
using stale data. I could also see it causing trouble if a model
had some sort of 'do_not_delete' flag that was changed right after
AR loaded the record.</p>
<p>So, it seems to me that #destroy should follow the same
optimistic locking logic as updates do. That is, add the current
lock version to the WHERE clause and raise a StaleObjectError if
the delete fails.</p>
<p>I've written a patch (with a test and updated documentation)
that accomplishes this.</p></div>
85
1
false
2009-12-27T23:06:43+00:00
11102
3624
fix-arrayto_xml-to-produce-valid-markup-when-working-with-namespaced-classes
0
8994
new
activesupport bug patch to_xml
Fix Array#to_xml to produce valid markup when working with namespaced classes
2010-02-01T01:17:49+00:00
84622
Mark Foster
Yaroslav Markin
Jeremy Kemper
http://rails.lighthouseapp.com/projects/8994/tickets/3624
How to reproduce:
@@@
@records = Namespaced::Model.all
render :xml => @records.to_xml
@@@
Before:
@@@
<namespaced/models>
<namespaced/model>
<!-- -->
</namespaced/model>
</namespaced/models>
@@@
After:
@@@
<namespaced-models>
<namespaced-model>
<!-- -->
</namespaced-model>
</namespaced-models>
@@@
How to reproduce:
@@@
@records = Namespaced::Model.all
render :xml => @records.to_xml
@@@
Before:
@@@
<namespaced/models>
<namespaced/model>
<!-- -->
</namespaced/model>
</namespaced/models>
@@@
After:
@@@
<namespaced-models>
<namespaced-model>
<!-- -->
</namespaced-model>
</namespaced-models>
@@@
<div><p>How to reproduce:</p>
<pre>
<code>@records = Namespaced::Model.all
render :xml => @records.to_xml</code>
</pre>
<p>Before:</p>
<pre>
<code><namespaced/models>
<namespaced/model>
<!-- -->
</namespaced/model>
</namespaced/models></code>
</pre>
<p>After:</p>
<pre>
<code><namespaced-models>
<namespaced-model>
<!-- -->
</namespaced-model>
</namespaced-models></code>
</pre></div>
1
false
2010-01-31T09:26:19+00:00
84622
3824
to_xml-generates-invalid-xml-for-arrays-of-namespaced-activerecords
0
8994
new
activerecord array bug patch to_xml xml
to_xml generates invalid xml for arrays of namespaced ActiveRecords
2010-01-31T23:42:16+00:00
11102
Yaroslav Markin
Mark Foster
http://rails.lighthouseapp.com/projects/8994/tickets/3824
The problem is similar to the one described in:
https://rails.lighthouseapp.com/projects/8994/tickets/2723-to_xml-generates-invalid-xml-with-namespaced-activerecord
That patch applied to a single ActiveRecord with namespaces. It turns out that the same problem occurs in arrays of ActiveRecords with namespaces as well, e. g., those returned by find(:all).
The prior patch fixed options[:root] in to_xml for ActiveRecords . However, if the ActiveRecords are in an array, then the value of options[:root] is set in in activesupport/lib/active_support/core_ext/array/conversions.rb to_xml method and passed in to activemodel/lib/active_model/serializers/xml.rb and it contains invalid xml characters. Since options[:root] is not nil, the prior patch has no effect on correcting the invalid characters in arrays of namespaced ActiveRecords.
This patch strips out the invalid characters for any classes with namespaces from the root set in the array to_xml method.
The problem is similar to the one described in:
https://rails.lighthouseapp.com/projects/8994/tickets/2723-to_xml-generates-invalid-xml-with-namespaced-activerecord
That patch applied to a single ActiveRecord with namespaces. It turns out that the same problem occurs in arrays of ActiveRecords with namespaces as well, e. g., those returned by find(:all).
The prior patch fixed options[:root] in to_xml for ActiveRecords . However, if the ActiveRecords are in an array, then the value of options[:root] is set in in activesupport/lib/active_support/core_ext/array/conversions.rb to_xml method and passed in to activemodel/lib/active_model/serializers/xml.rb and it contains invalid xml characters. Since options[:root] is not nil, the prior patch has no effect on correcting the invalid characters in arrays of namespaced ActiveRecords.
This patch strips out the invalid characters for any classes with namespaces from the root set in the array to_xml method.
<div><p>The problem is similar to the one described in:</p>
<p><a href=
"https://rails.lighthouseapp.com/projects/8994/tickets/2723-to_xml-generates-invalid-xml-with-namespaced-activerecord">
https://rails.lighthouseapp.com/projects/8994/tickets/2723-to_xml-g...</a></p>
<p>That patch applied to a single ActiveRecord with namespaces. It
turns out that the same problem occurs in arrays of ActiveRecords
with namespaces as well, e. g., those returned by find(:all).</p>
<p>The prior patch fixed options[:root] in to_xml for ActiveRecords
. However, if the ActiveRecords are in an array, then the value of
options[:root] is set in in
activesupport/lib/active_support/core_ext/array/conversions.rb
to_xml method and passed in to
activemodel/lib/active_model/serializers/xml.rb and it contains
invalid xml characters. Since options[:root] is not nil, the prior
patch has no effect on correcting the invalid characters in arrays
of namespaced ActiveRecords.</p>
<p>This patch strips out the invalid characters for any classes
with namespaces from the root set in the array to_xml method.</p></div>
1
false
2010-01-30T15:44:01+00:00
45230
3819
use-assert_raise-instead-of-assert_raises
0
8994
new
assertions patch
Use assert_raise instead of assert_raises
2010-01-30T15:44:07+00:00
45230
Matt Duncan
Matt Duncan
http://rails.lighthouseapp.com/projects/8994/tickets/3819
Ruby docs state that assert_raises will be deprecated (I assume sometime) in Ruby 1.9 in favor of assert_raise.
http://ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html#M004509
See also #1617 which cleaned everything up a little over a year ago.
The attached patch is for master, let me know if a 2.3 patch would be useful too.
Ruby docs state that assert_raises will be deprecated (I assume sometime) in Ruby 1.9 in favor of assert_raise.
http://ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html#M004509
See also #1617 which cleaned everything up a little over a year ago.
The attached patch is for master, let me know if a 2.3 patch would be useful too.
<div><p>Ruby docs state that assert_raises will be deprecated (I assume
sometime) in Ruby 1.9 in favor of assert_raise.</p>
<p><a href=
"http://ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html#M004509">
http://ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/...</a></p>
<p>See also <a href="/projects/8994/tickets/1617" title=
"Ticket #1617">#1617</a> which cleaned everything up a little over
a year ago.</p>
<p>The attached patch is for master, let me know if a 2.3 patch
would be useful too.</p></div>
1
false
2010-01-30T08:17:59+00:00
8163
3817
when-routing-creates-a-singular-resource-it-doesnt-add-itself-to-name_prefix
0
8994
new
3.0 patch rails3 resource routing
When routing creates a singular resource, it doesn't add itself to name_prefix
2010-01-30T08:18:04+00:00
8163
Eugene Pimenov
Eugene Pimenov
http://rails.lighthouseapp.com/projects/8994/tickets/3817
Routing code:
resource :subscription do
get :renew
resources :cards
end
Generates these routes (irrelevant parts skipped):
GET /subscription/renew(.:format) {:action=>"renew", :controller=>"subscriptions"}
GET /subscription/cards(.:format) {:action=>"index", :controller=>"cards"}
cards POST /subscription/cards(.:format) {:action=>"create", :controller=>"cards"}
new_card GET /subscription/cards/new(.:format) {:action=>"new", :controller=>"cards"}
edit_card GET /subscription/cards/:id/edit(.:format) {:action=>"edit", :controller=>"cards"}
As you can see, there's no method for renew and cards methods aren't name prefixed.
Routing code:
resource :subscription do
get :renew
resources :cards
end
Generates these routes (irrelevant parts skipped):
GET /subscription/renew(.:format) {:action=>"renew", :controller=>"subscriptions"}
GET /subscription/cards(.:format) {:action=>"index", :controller=>"cards"}
cards POST /subscription/cards(.:format) {:action=>"create", :controller=>"cards"}
new_card GET /subscription/cards/new(.:format) {:action=>"new", :controller=>"cards"}
edit_card GET /subscription/cards/:id/edit(.:format) {:action=>"edit", :controller=>"cards"}
As you can see, there's no method for renew and cards methods aren't name prefixed.
<div><p>Routing code:</p>
<pre>
<code>resource :subscription do
get :renew
resources :cards
end</code>
</pre>
<p>Generates these routes (irrelevant parts skipped):<br></p>
<pre>
<code> GET /subscription/renew(.:format) {:action=>"renew", :controller=>"subscriptions"}
GET /subscription/cards(.:format) {:action=>"index", :controller=>"cards"}
cards POST /subscription/cards(.:format) {:action=>"create", :controller=>"cards"}
new_card GET /subscription/cards/new(.:format) {:action=>"new", :controller=>"cards"}
edit_card GET /subscription/cards/:id/edit(.:format) {:action=>"edit", :controller=>"cards"}</code>
</pre>
<p>As you can see, there's no method for renew and cards methods
aren't name prefixed.</p></div>
141
5
false
2009-09-09T22:15:07+01:00
69218
27004
3178
mass-assignment-security-refactoring
2
8994
open
activerecord bugmash patch
Mass Assignment Security Refactoring
2010-01-30T02:10:59+00:00
69218
Eric Chapweske
Eric Chapweske
Michael Koziarski
http://rails.lighthouseapp.com/projects/8994/tickets/3178
3.0
This patch provides a rewrite that is hopefully more understandable and modular than the existing code. This should allow developers and plugin authors to experiment a bit more without introducing massive security holes. E.g., it's pretty trivial to move responsibility over to a controller by including ActiveRecord::MassAssignmentSecurity and adding a couple helper methods. This is my first contribution attempt so hopefully I didn't mess up too much ;)
This patch provides a rewrite that is hopefully more understandable and modular than the existing code. This should allow developers and plugin authors to experiment a bit more without introducing massive security holes. E.g., it's pretty trivial to move responsibility over to a controller by including ActiveRecord::MassAssignmentSecurity and adding a couple helper methods. This is my first contribution attempt so hopefully I didn't mess up too much ;)
<div><p>This patch provides a rewrite that is hopefully more
understandable and modular than the existing code. This should
allow developers and plugin authors to experiment a bit more
without introducing massive security holes. E.g., it's pretty
trivial to move responsibility over to a controller by including
ActiveRecord::MassAssignmentSecurity and adding a couple helper
methods. This is my first contribution attempt so hopefully I
didn't mess up too much ;)</p></div>
15783
0
false
2008-09-09T18:28:28+01:00
22990
9903
1004
datetime_select-to-accept-ampm-option
445
8994
incomplete
activerecord enhancement helper patch
datetime_select to accept :ampm option
2010-01-28T18:33:31+00:00
22990
Yong Bakos
Yong Bakos
Geoff Buesing
http://rails.lighthouseapp.com/projects/8994/tickets/1004
2.x
I'd like to propose the development of a patch to core that adds the capability of the datetime_select to render a 12-hour selectlist for the hour, and an am/pm selectlist.
Previous plugin/module solutions to this are old, I couldn't find anything relevant on github, and this just seems (to me) like it should belong in core.
I belive this this will also require changes to AR.
Patch to come, unless this ticket gets nixed.
I'd like to propose the development of a patch to core that adds the capability of the datetime_select to render a 12-hour selectlist for the hour, and an am/pm selectlist.
Previous plugin/module solutions to this are old, I couldn't find anything relevant on github, and this just seems (to me) like it should belong in core.
I belive this this will also require changes to AR.
Patch to come, unless this ticket gets nixed.
<div><p>I'd like to propose the development of a patch to core that adds
the capability of the datetime_select to render a 12-hour
selectlist for the hour, and an am/pm selectlist.</p>
<p>Previous plugin/module solutions to this are old, I couldn't
find anything relevant on github, and this just seems (to me) like
it should belong in core.</p>
<p>I belive this this will also require changes to AR.</p>
<p>Patch to come, unless this ticket gets nixed.</p></div>
8406
1
false
2010-01-20T23:28:08+00:00
136
3760
make-ar-guess-the-inverse-of-an-association-if-not-specified
1
8994
open
activerecord inverse_of patch
Make AR guess the inverse of an association if not specified
2010-01-26T18:31:24+00:00
85
Jeremy Kemper
Murray Steele
Eloy Duran
http://rails.lighthouseapp.com/projects/8994/tickets/3760
Change ActiveRecord so that if the model doesn't specify an explicit :inverse_of option AR will try to guess and give the model the benefits of :inverse_of. In some cases AR won't be able to guess, or will guess wrong, so you can still specify explcitly using :inverse_of. You can also turn off the feature on a case by case basis if you specify :inverse_of => nil.
You might want to do this if you have validations or autosaves on your associations that might cause an infinite loop.
Change ActiveRecord so that if the model doesn't specify an explicit :inverse_of option AR will try to guess and give the model the benefits of :inverse_of. In some cases AR won't be able to guess, or will guess wrong, so you can still specify explcitly using :inverse_of. You can also turn off the feature on a case by case basis if you specify :inverse_of => nil.
You might want to do this if you have validations or autosaves on your associations that might cause an infinite loop.
<div><p>Change ActiveRecord so that if the model doesn't specify an
explicit :inverse_of option AR will try to guess and give the model
the benefits of :inverse_of. In some cases AR won't be able to
guess, or will guess wrong, so you can still specify explcitly
using :inverse_of. You can also turn off the feature on a case by
case basis if you specify :inverse_of => nil.</p>
<p>You might want to do this if you have validations or autosaves
on your associations that might cause an infinite loop.</p></div>
1
false
2009-11-30T07:53:52+00:00
11354
3521
patch-add-conditional-counter-cache
179947
8994
new
2-3-stable counter_cache patch
[PATCH] Add conditional counter cache
2010-01-26T16:42:01+00:00
11354
Scott Windsor
Scott Windsor
http://rails.lighthouseapp.com/projects/8994/tickets/3521
One common pattern that I keep repeating is lots of repeated code to handle cache counters based on a flag or status. Take the example of Posts & Comments. I want a counter cache for comments, but I don't want to include ones that are deleted. This should also take into account updates as well as creates & deletes.
Here's an example of the syntax:
belongs_to :post, :counter_cache => {:condition => lambda {|c| !c.deleted } }
This only increments or decrements the counter if the lambda returns true (and the lambda has self passed in).
I've added support for this in the following patch. I've also included unit tests for this functionality. This works in 2-3-stable, but I haven't tested against master.
One common pattern that I keep repeating is lots of repeated code to handle cache counters based on a flag or status. Take the example of Posts & Comments. I want a counter cache for comments, but I don't want to include ones that are deleted. This should also take into account updates as well as creates & deletes.
Here's an example of the syntax:
belongs_to :post, :counter_cache => {:condition => lambda {|c| !c.deleted } }
This only increments or decrements the counter if the lambda returns true (and the lambda has self passed in).
I've added support for this in the following patch. I've also included unit tests for this functionality. This works in 2-3-stable, but I haven't tested against master.
<div><p>One common pattern that I keep repeating is lots of repeated
code to handle cache counters based on a flag or status. Take the
example of Posts & Comments. I want a counter cache for
comments, but I don't want to include ones that are deleted. This
should also take into account updates as well as creates &
deletes.</p>
<p>Here's an example of the syntax:</p>
<p>belongs_to :post, :counter_cache => {:condition => lambda
{|c| !c.deleted } }</p>
<p>This only increments or decrements the counter if the lambda
returns true (and the lambda has self passed in).</p>
<p>I've added support for this in the following patch. I've also
included unit tests for this functionality. This works in
2-3-stable, but I haven't tested against master.</p></div>
85
5
false
2009-08-03T22:27:35+01:00
64992
2990
none-standard-id-column-on-has_many-through
130019
8994
open
bugmash hasmany patch primarykey review
[PATCH] Non standard ID column on has_many :through
2010-01-25T17:20:40+00:00
25293
Prem Sichanugrist (sikachu)
James Pearson
Jeremy Kemper
http://rails.lighthouseapp.com/projects/8994/tickets/2990
Usingthe example code below:
class User < ActiveRecord::Base
has_many :followers
has_many :suspects, :through => :followers
end
class Connection < ActiveRecord::Base
belongs_to :user
belongs_to :suspect, :primary_key => :case_id , :foreign_key => :case_id
end
class Suspect < ActiveRecord::Base
belongs_to :connection, :primary_key => :case_id , :foreign_key => :case_id
end
The problem is that the belongs_to seems to ignore the :primary key.
If I do
u = User.find(:first)
u.suspects
The SQL generated is:
SELECT `suspects`.* FROM `suspects` INNER JOIN `connections` ON `suspects`.id = `connections`.case_id WHERE ((`followers`.user_id = 1))
However it should be:
SELECT `suspects`.* FROM `suspects` INNER JOIN `connections` ON `suspects`.case_id = `connections`.case_id WHERE ((`followers`.user_id = 1))
This was partially fixed in 2.3.3 but not for has_many :through.
The patch applied to 2.3.3 can be found here: http://github.com/rails/rails/commit/b3ec7b2d03a52e43a4451d522eea7e6499289daa
Usingthe example code below:
class User < ActiveRecord::Base
has_many :followers
has_many :suspects, :through => :followers
end
class Connection < ActiveRecord::Base
belongs_to :user
belongs_to :suspect, :primary_key => :case_id , :foreign_key => :case_id
end
class Suspect < ActiveRecord::Base
belongs_to :connection, :primary_key => :case_id , :foreign_key => :case_id
end
The problem is that the belongs_to seems to ignore the :primary key.
If I do
u = User.find(:first)
u.suspects
The SQL generated is:
SELECT `suspects`.* FROM `suspects` INNER JOIN `connections` ON `suspects`.id = `connections`.case_id WHERE ((`followers`.user_id = 1))
However it should be:
SELECT `suspects`.* FROM `suspects` INNER JOIN `connections` ON `suspects`.case_id = `connections`.case_id WHERE ((`followers`.user_id = 1))
This was partially fixed in 2.3.3 but not for has_many :through.
The patch applied to 2.3.3 can be found here: http://github.com/rails/rails/commit/b3ec7b2d03a52e43a4451d522eea7e6499289daa
<div><p>Usingthe example code below:</p>
<p>class User < ActiveRecord::Base has_many :followers has_many
:suspects, :through => :followers end</p>
<p>class Connection < ActiveRecord::Base belongs_to :user
belongs_to :suspect, :primary_key => :case_id , :foreign_key
=> :case_id end</p>
<p>class Suspect < ActiveRecord::Base belongs_to :connection,
:primary_key => :case_id , :foreign_key => :case_id end</p>
<p>The problem is that the belongs_to seems to ignore the :primary
key.</p>
<p>If I do</p>
<p>u = User.find(:first) u.suspects</p>
<p>The SQL generated is:</p>
<p>SELECT <code>suspects</code>.* FROM <code>suspects</code> INNER
JOIN <code>connections</code> ON <code>suspects</code>.id =
<code>connections</code>.case_id WHERE
((<code>followers</code>.user_id = 1))</p>
<p>However it should be:</p>
<p>SELECT <code>suspects</code>.* FROM <code>suspects</code> INNER
JOIN <code>connections</code> ON <code>suspects</code>.case_id =
<code>connections</code>.case_id WHERE
((<code>followers</code>.user_id = 1))</p>
<p>This was partially fixed in 2.3.3 but not for has_many
:through.</p>
<p>The patch applied to 2.3.3 can be found here: <a href="http://github.com/rails/rails/commit/b3ec7b2d03a52e43a4451d522eea7e6499289daa">
http://github.com/rails/rails/co...</a></p></div>
2
false
2009-07-14T00:02:38+01:00
22106
2010-01-15T00:00:00+00:00
50064
2907
custom-counter_cache-is-not-used-when-using-collectionsize-method
6
8994
open
2.3.6 active_record collection counter_cache patch
Custom counter_cache is not used when using collection.size method
2010-01-25T10:40:54+00:00
59355
pablo (at teambox)
Szymon Nowak
http://rails.lighthouseapp.com/projects/8994/tickets/2907
2.3.6
While writing a patch for belongs_to association, I've encountered the following issue:
@@@ ruby
class Author < AR::Base
has_many :posts
end
class Post < AR::Base
belongs_to :author, :counter_cache => "custom_posts_count"
end
a = Author.create
p = Post.create
p.author = a # updates counter on Author, but doesn't save post object
Author.find(a.id).send(:read_attribute, "custom_posts_count" # 1; uses counter cache
Author.find(a.id).posts.size # 0; uses SQL count
@@@
In the second example SQL count is used because in HasManyAssociation#count_records method, there's check if there's cache counter:
@@@ ruby
def has_cached_counter?
@owner.attribute_present?(cached_counter_attribute_name)
end
def cached_counter_attribute_name
"#{@reflection.name}_count"
end
@@@
which fails in this case. It simply uses name of the reflection, not the value of :counter_cache option on belongs_to association, or table name as described in [docs](http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#M002125).
Not sure if there's an easy solution for this if counter cache column name is defined on belongs_to association and not has_many.
While writing a patch for belongs_to association, I've encountered the following issue:
@@@ ruby
class Author < AR::Base
has_many :posts
end
class Post < AR::Base
belongs_to :author, :counter_cache => "custom_posts_count"
end
a = Author.create
p = Post.create
p.author = a # updates counter on Author, but doesn't save post object
Author.find(a.id).send(:read_attribute, "custom_posts_count" # 1; uses counter cache
Author.find(a.id).posts.size # 0; uses SQL count
@@@
In the second example SQL count is used because in HasManyAssociation#count_records method, there's check if there's cache counter:
@@@ ruby
def has_cached_counter?
@owner.attribute_present?(cached_counter_attribute_name)
end
def cached_counter_attribute_name
"#{@reflection.name}_count"
end
@@@
which fails in this case. It simply uses name of the reflection, not the value of :counter_cache option on belongs_to association, or table name as described in [docs](http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#M002125).
Not sure if there's an easy solution for this if counter cache column name is defined on belongs_to association and not has_many.
<div><p>While writing a patch for belongs_to association, I've
encountered the following issue:</p>
<pre><code class="ruby">
class Author < AR::Base
has_many :posts
end
class Post < AR::Base
belongs_to :author, :counter_cache => "custom_posts_count"
end
a = Author.create
p = Post.create
p.author = a # updates counter on Author, but doesn't save post object
Author.find(a.id).send(:read_attribute, "custom_posts_count" # 1; uses counter cache
Author.find(a.id).posts.size # 0; uses SQL count
</code></pre>
<p>In the second example SQL count is used because in
HasManyAssociation#count_records method, there's check if there's
cache counter:</p>
<pre><code class="ruby">
def has_cached_counter?
@owner.attribute_present?(cached_counter_attribute_name)
end
def cached_counter_attribute_name
"#{@reflection.name}_count"
end
</code></pre>
<p>which fails in this case. It simply uses name of the reflection,
not the value of :counter_cache option on belongs_to association,
or table name as described in <a href="/projects/8994/changesets/docs" title="Changeset 'docs'">[docs]</a>(<a href="http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#M002125">http://api.rubyonrails.org/class...</a>).</p>
<p>Not sure if there's an easy solution for this if counter cache
column name is defined on belongs_to association and not
has_many.</p></div>