error when hiding a project
I get the following error on the latest git revision (0b88c72570efea336e00fa017a084c6463f2763c) when I try to set a project to hidden:
Processing ProjectsController#update (for 127.0.0.1 at 2011-09-07 14:09:43) [PUT]
Parameters: {"6"=>"e", "11"=>"w", "_source_view"=>"project", "7"=>"_", "12"=>"=", "8"=>"v", "13"=>"p", "9"=>"i", "14"=>"r", "authenticity_token"=>"cutout=", "15"=>"o", "id"=>"16", "project"=>{"name"=>"muhmuhmuh", "default_tags"=>"", "default_context_name"=>"computer", "description"=>"", "state"=>"hidden"}, "0"=>"_", "16"=>"j", "1"=>"s", "17"=>"e", "2"=>"o", "18"=>"c", "3"=>"u", "19"=>"t", "wants_render"=>"true", "4"=>"r", "10"=>"e", "5"=>"c"}
AASM::InvalidTransition (Event 'hide' cannot transition from 'project_hidden'):
aasm (2.2.0) lib/aasm/event.rb:12:in `fire'
aasm (2.2.0) lib/aasm/aasm.rb:155:in `aasm_fire_event'
aasm (2.2.0) lib/aasm/aasm.rb:53:in `hide!'
app/models/project.rb:60:in `hide_todos'
/opt/local/lib/ruby/gems/1.8/gems/will_paginate-2.3.16/lib/will_paginate/finder.rb:168:in `method_missing'
/opt/local/lib/ruby/gems/1.8/gems/will_paginate-2.3.16/lib/will_paginate/finder.rb:168:in `method_missing'
app/models/project.rb:58:in `hide_todos'
aasm (2.2.0) lib/aasm/state.rb:47:in `send'
aasm (2.2.0) lib/aasm/state.rb:47:in `_call_action'
aasm (2.2.0) lib/aasm/state.rb:22:in `call_action'
aasm (2.2.0) lib/aasm/state.rb:19:in `catch'
aasm (2.2.0) lib/aasm/state.rb:19:in `call_action'
aasm (2.2.0) lib/aasm/aasm.rb:164:in `aasm_fire_event'
aasm (2.2.0) lib/aasm/aasm.rb:53:in `hide!'
app/models/project.rb:102:in `transition_to'
app/controllers/projects_controller.rb:148:in `update'
Leave a comment
How does this project look like. Are there todos in there which are hidden?
The error is about a todo that Tracks tries to hide (todo.hide!) but is already hidden (project_hidden state). This should not occur, hence the error. Question is, how did this project/todo get in this state?
The error is about a todo that Tracks tries to hide (todo.hide!) but is already hidden (project_hidden state). This should not occur, hence the error. Question is, how did this project/todo get in this state?
Now there's something really strange.
The error goes away when I mark a specific todo as complete. I wanted to give you the xml details of that todo, however, it doesn't show up on todos.xml. I'll attach an an output of the sqlite entry.
I've no clue how it got into that state.
The error goes away when I mark a specific todo as complete. I wanted to give you the xml details of that todo, however, it doesn't show up on todos.xml. I'll attach an an output of the sqlite entry.
I've no clue how it got into that state.
on 2011-09-14 14:22 *
By lrbalt
Assigned to set to lrbalt
Status changed from New to Fixed
Assigned to set to lrbalt
Status changed from New to Fixed
(In revision:a332f8f5575789a937143e4f536ad81c45bb94c3) fix #1196. You can now transition from pending to project_hidden
One side effect though: althoug dependencies are still in place, the gui cannot differentiate between pending and hidden todos. The views currently do not show dependencies anymore in hidden projects. Postponing a fix for 2.2
Signed-off-by: Reinier Balt <lrbalt@gmail.com>
Branch: master
One side effect though: althoug dependencies are still in place, the gui cannot differentiate between pending and hidden todos. The views currently do not show dependencies anymore in hidden projects. Postponing a fix for 2.2
Signed-off-by: Reinier Balt <lrbalt@gmail.com>
Branch: master
your trace was probably from later in time, after the first change to hidden project. With the db you sent me privately I saw that you were trying to hide a project with dependent todos (I could have known because of your wish for sequential projects :-) ). So the cause was transitioning from pending state to project_hidden state. This causes an error for the pending todos, but was succesfull for the first active todo. The result was a db in incorrect state.
You hit a flaw in our state machine. Todos could be in a hidden project and are pending at the same time. We set a state 'project_hidden' on all todos that are in a hidden project. This is a wrong implementation and need to be fixed in a future release. I was planning to overhaul the state machine for 2.2, because handling hidden todos (that could also be in a hidden context, but the state then remains 'active') is awful.
With this fix, at least the db remains its integrity, but the views do not handle hidden project with dependencies. You will see a project that looks like its actions are not dependent on each other (but they are). If you unhide the project, the dependencies will be visible again.
You hit a flaw in our state machine. Todos could be in a hidden project and are pending at the same time. We set a state 'project_hidden' on all todos that are in a hidden project. This is a wrong implementation and need to be fixed in a future release. I was planning to overhaul the state machine for 2.2, because handling hidden todos (that could also be in a hidden context, but the state then remains 'active') is awful.
With this fix, at least the db remains its integrity, but the views do not handle hidden project with dependencies. You will see a project that looks like its actions are not dependent on each other (but they are). If you unhide the project, the dependencies will be visible again.
(In revision:3e7f748301b0fd08b89bab6f672116232b663648) fix #1196. You can now transition from pending to project_hidden
One side effect though: althoug dependencies are still in place, the gui cannot differentiate between pending and hidden todos. The views currently do not show dependencies anymore in hidden projects. Postponing a fix for 2.2
Signed-off-by: Reinier Balt <lrbalt@gmail.com>
Branch: 2.0_branch
One side effect though: althoug dependencies are still in place, the gui cannot differentiate between pending and hidden todos. The views currently do not show dependencies anymore in hidden projects. Postponing a fix for 2.2
Signed-off-by: Reinier Balt <lrbalt@gmail.com>
Branch: 2.0_branch