I am using this plugin for several months already without problems in a Rails 3 app.
Now I updated from Rails 3.0.1 to 3.0.2 and suddenly the position column is not incremented beyond 2... meaning I have the following:

class Question < ActiveRecord::Base
  has_many   :answers
end

class Answer < ActiveRecord::Base
  belongs_to :question

  acts_as_list :scope => :question
end

My Answer model has a position column. When I create X answers for a question, I expect the positions to be 1, 2, 3, and 4.
With Rails 3.0.2 they are 1, 2, 2, and 2.
I tried running the tests included in the plugin locally and all passed, even with AR 3.0.3.
If anyone has a pointer to what might be the problem, I could investigate further.

During cucumber tests, "[BUG] Segmentation fault" exceptions occurred when Rails loaded models with acts_as_list. I don't know if this was directly caused by acts_as_list, but removing it solved the issue for me.

I'm using 'remove_from_list' and a deleted_at attribute to remove items from list. The problem is that when creating a new record, if there are other records in the list with position of null, all new records get set to position 1. A workaround I've used is to set a default scope of :conditions => (:position ^ nil), but it seems to me at least, that the private method 'bottom_item' should have a default condition of position not nil.

If so, can we change it to use this plugin? There's some annoying bugs in the 0.1.2 release such, as update right before destroy.

If find this an unexpected result from the #insert_at(pos) method:

Suppose you have:
1 A
2 B
3 C
4 D
5 E
6 F
7 G

And you move E to position 3 (before C) by #insert_at(3) the result will be as expected:
1 A
2 B
3 E
4 C
5 D
6 F
7 G

But now - starting all over - you move C to position 6 (before F), the result will be unexpected:
1 A
2 B
3 D
4 E
5 F
6 C
7 G

Technically, yes C has arrived on position 6, but NOT before 'F' as meant to be from a sorting point of view.

I consider this an issue. One way to solve it, is by adding a new method #move_to(pos) ?

If you have a scope defined as a string, like:
'todo_list_id = #{todo_list_id} AND completed = 0'

it doesn't generate a valid SQL when todo_list_id is null.

PostgreSQL does not work with:
acts_as_list :scope => 'article_section_id', :column => 'sort_order'

When I run:
ArticleSection.find(1234).articles.create(title: "Test1")

It results in following error: ActiveRecord::StatementInvalid: PG::Error: ERROR: argument of WHERE must be type boolean, not type integer

because this SQL being executed:
SELECT "articles".* FROM "articles" WHERE (article_section_id) ORDER BY articles.sort_order DESC LIMIT 1

I was able to fix it basded on very old blog post: http://www.mattmccray.com/archive/2006/07/19/Comatose_and_PostgreSQL

All that I had to do was to change string names to symbols:
acts_as_list scope: :article_section_id, column: :sort_order

I report it since it looks like bug to me.

Calling move_to_bottom causes the following warning:

DEPRECATION WARNING: update_attribute is deprecated and will be removed in Rails 4. If you want to skip mass-assignment protection, callbacks, and modifying updated_at, use update_column. If you do want those things, use update_attributes.

Fails because no quoting for column name in SQL commands.

Example:
acts_as_list :column => :order
and other reserved for SQL words.

Duplicates are created if the child_attributes hash is set. Note that this occurs without even saving the model. Using the example in the README, if you include accepts_nested_attributes_for :todo_items and in a console wrote todo_list.todo_items_attributes = {"1" => { "position" => "1" } } you'd see the duplicate with todo_list.todo_items.

When acts_as_list is used on an abstract class, which has multiple subclasses, in some cases the plugin tries to get the order of the items in the abstract class.

This of course fails (the table cannot be found).

My solution was to add a check for this:

def acts_as_list(options = {})
    return if abstract_class
    ...

I can store a relation that is a graph in fact. Is it expected? I think it should throw an exception when it recycling. Here is the test (please note that this test passes; however i am expecting it to fail):

category = Category.new
category.name="Parent"
category.save
child = category.children.create("name" => "child_1")
child.children = [category]
assert category.save
loadedChild = Category.find_by_name("child_1")
assert_equal "Parent", loadedChild.parent.name
assert_equal "Parent", loadedChild.children[0].name

lib/active_record/acts/list.rb:67

http://github.com/rails/acts_as_list/blob/master/lib/active_record/acts/list.rb#L67

should be 'before_validation_on_create' since 'before_create' comes after validations, which means you can't have validations on the value of 'position'.

Hi all
Models (Rails 3 application):
class NetworkService < ActiveRecord::Base
has_many :network_classes, :foreign_key => "network_id", :order => :position
end
class NetworkClass < ActiveRecord::Base
belongs_to :class_definition, :foreign_key => "class_id"
belongs_to :network_service, :foreign_key => "network_id"
acts_as_list :scope => :network_id
validates_presence_of :class_id, :network_id
attr_accessible :class_id, :network_id
end

Case:

• when I create an element in NetworkClass, no problem it goes straight at the end of the current list.
• when I update the "network_id" attribute which holds the "scope", the record is saved with a "position" set to 1, no matter if there are already records with the same "network_id". I would expect that the "position" of the updated record is set to the (last position + 1) of the list corresponding to the new "network_id" value. You then end up with multiple records with the same position in the list.
• note: the NetworkClass "belongs to" another "class_definition" table, but not concerned with the list (I guess)

Many thanks for the gem anyway

Any list update operation that uses update_all (decrement_positions_on_higher_items, decrement_positions_on_lower_items, increment_positions_on_higher_items, increment_positions_on_lower_items, increment_positions_on_all_items) is not updating the locking_column which can cause concurrency problems when the list can be edited by multiple users simultaneously.