Redmine

One more info:
The problem is even worse, because after one wrong submission, all new subtasks will become child of the last child, avoiding the creation of a subtask of the parent for ever.

As visible on the demo I've been able to reproduce the described behaviour there.
I don't know though if it's something that should be fixed inside Redmine. This seems more of an issue that might affect more Rails-based apps. Though I might be wrong here... 8-)

There's a simple fix to this, as did in #6826:

Disable 'Add' button after click!

I can have a look at this later today since I worked on #6826.

Good to see it could be fixed soon. I can confirm this bug is still present on demo, and created another ticket there to demonstrate the problem:

http://demo.redmine.org/issues/2896

All descendants of 2896 should be children, but they are shown in different (wrong) levels.

As I said above, I believe the fix applied to #6826 can fix this too, without much work. Please post here if you need some help with this.

I wonder if this may be fixed with a transaction isolation explicit setting somewhere (if there is a transaction) ?

Don't know much about RoR, but at least in Java we're used to make each request have its own transaction, making this approach harder than avoid the double click.

The only downside I see on using the 'avoid double click' solution is if more than one user tries to create children for an issue at the exactly same time, which is very unlikely.

Well, there is no transaction and 2 successive DML (which explain #7667) : #save does the insert and #after_save => #update_nested_set_attributes does an update of the hierarchy.

Doing a single insert (that is, do not call #update_nested_set_attributes after save but before) can be buggy too.

Edit May, 11th : Actually, there is a transaction managed by RoR ActiveRecord.

Hi, we have this problem in our installation too. Our "work around", re-create the task (duplicate) and re-do the parent relationship.
Here is part of the dump:

  app/models/issue.rb:442:in `soonest_start'
  /var/lib/gems/1.8/gems/ruby-ole-1.2.11.1/lib/ole/support.rb:40:in `send'
  /var/lib/gems/1.8/gems/ruby-ole-1.2.11.1/lib/ole/support.rb:40:in `to_proc'
  app/models/issue.rb:442:in `soonest_start'
  app/models/issue.rb:272:in `validate'
  app/models/issue.rb:498:in `save_issue_with_child_records'
  app/models/issue.rb:487:in `save_issue_with_child_records'

Hi, we have this problem too. My question is - can I manually set the lft/rgt values directly in DB instead of the copying the issues and recreating the hierarchy? What will be the proper values for lft/rgt and for what these columns are defined?

Yes, you can do it, but need to take care. you should do a backup first just in case.

lft and rgt tell redmine how it should build the tree. They hold the visit and unvisit index on a depth-first search on the tree. Example:

• Parent (lft 1, rgt 10)
  • Child 1 (lft 2, rgt 3)
  • Child 2 (lft 4, rgt 9)
    • Grandson 1 (lft 5, rgt 6)
    • Grandson 2 (lft 7, rgt 8)

Parent is the first to be visited (lft=1), and the last to be unvisited (rgt=10), and so on... These should be calculated for all tickets with the same root. The root will have always lft=1 and rgt = #tickets * 2.

This also happens when copying a project

This it's a workaround...

#8537

This solves part of the problem, but pressing the back button and redo the operation

Reproduced again,

http://demo.redmine.org/issues/2701

Just met this problem in my environment (1.2.1). Surprised it's not fixed for such a long time.

If it's so hard to fix, is there any scripts that could fix or recalculate lft/rgt values after a curruption?

Gary Shi wrote:

(...) is there any scripts that could fix or recalculate lft/rgt values after a curruption?

Try to run

ruby script/runner -e production 'Project.rebuild!'

from your Redmine base directory.

Edit: I mean Issue.rebuild! but didn't try yet so I advise you to make a DB dump before.

I found it possible to reset the parent/child relationships with:

UPDATE `redmine`.`projects` SET lft = 2 * id - 1, rgt = 2 * id;

This will make each of the projects have no parents and no subordinates (as their left [bookend] and right [bookend] are just one number apart).

Knowing this is how the relationship is derived, should allow you to isolate problems more easily. You can actually remove sub-projects just by not having a lft and rgt number within a parent project's lft-rgt range.

I worked hard to migrate from 0.8.4 to 1.3.1 and had to deal directly with the DBs where this situation came into play.

Hit this issue with the following scenario:
Two users concurrently update two different issues and assign the same parent id to both of them.
Hierarchy of the parent task becomes broken and access to its children may cause process hanging or crashing.

SQL for detecting broken hierarchies:

select distinct parent_id
from issues 
where parent_id is not null
group by parent_id, rgt 
having count(*) > 1

It seems to be fixed after #6555. I couldn't reproduce anymore on demo: http://demo.redmine.org/projects/test6579

Someone could review it and mark as fixed?

"Parent task translation missing: en, activerecord, errors, models, issue, attributes, parent_issue_id, not_a_valid_parent"

I think I still got the issue.
Not sure how its produced.

Happens when trying to update subtask.

Version: Redmine 1.3.2.stable

I think I'm getting same issue with redmine 2.1.2.
I've posted this topic to the board: http://www.redmine.org/boards/2/topics/33878
Sory if I did something wrong.

Note that this also affects projects on Redmine 1.4.

The workaround is to run:

X_DEBIAN_SITEID=koumbit RAILS_ENV=production  ./script/runner 'Project.rebuild!'

(X_DEBIAN_SITEID= is a local hack in the debian package.) This will rebuild the lft and rgt columns that are corrupted. It may mean that the order of projects changes, but the parent/child relationship will stay.

Hi, we're also having this problem. We've tried running Issue.rebuild! but unfortunately it failed with

[FATAL] failed to allocate memory.

This happened with both 1GB and then subsequently 8GB of memory.

We're going to retry with 30GB, but I'm dubious that this will fix it - can anyone offer any advice? (We have just over 100,000 tickets in our Redmine installation.)

Redmine 2.3.0.stable
Ruby 1.9.3
Rails 3.2.13

How many tickets do you have with problems? If not so much, you can try to edit them and hopefully they will be fixed. Sometimes it worked.

awesome_nested_set uses lock since 2.0.2.

https://github.com/collectiveidea/awesome_nested_set/blob/v2.1.6/CHANGELOG#L48

2.0.2
  ...
  * Added row locking and fixed some race conditions. [Markus J. Q. Roberts]

I think recent awesome_nested_set (2.1.6) and r12927 fix this issue.

Toshi, let me know when it's available on demo.redmine.org and I can test it to make sure it's ok.

Bruno Medeiros wrote:

Toshi, let me know when it's available on demo.redmine.org and I can test it to make sure it's ok.

demo.redmine.org is managed by JPL, not me.
So, I don't know when it is available.

It seems okay to have 1 and 2 if the issue has no hierarchy, what do you expect ?

Toshi MARUYAMA wrote:

But, I am not sure it is safe we don't use explicit transaction.

Toshi, what do you mean? Nested set update is done in AR callbacks that are wrapped in a transaction.

OK. I can see "BEGIN" and "COMMIT" on MySQL development.log

$ grep -n -3 -e BEGIN -e COMMIT log/development.log
296-  Issue Load (0.3ms)  SELECT  `issues`.* FROM `issues` WHERE `issues`.`id` = 1 LIMIT 1
297-  CACHE (0.0ms)  SELECT `roles`.* FROM `roles`
298-  CACHE (0.0ms)  SELECT DISTINCT `issue_statuses`.* FROM `issue_statuses` INNER JOIN `workflows` ON `workflows`.`new_status_id` = `issue_statuses`.`id` AND `workflows`.`type` IN ('WorkflowTransition') WHERE `workflows`.`old_status_id` = 1 AND `workflows`.`tracker_id` = 1 AND `workflows`.`role_id` IN (1, 2, 3, 4, 5) AND (author = 1 OR assignee = 0)  [["old_status_id", 1], ["tracker_id", 1]]
299:   (0.1ms)  BEGIN
300-  Issue Load (0.3ms)  SELECT `issues`.* FROM `issues` WHERE `issues`.`parent_id` = 8  ORDER BY `issues`.`lft` ASC
301-  IssueRelation Load (0.1ms)  SELECT `issue_relations`.* FROM `issue_relations` WHERE `issue_relations`.`issue_from_id` = 8
302-  Issue Load (0.2ms)  SELECT `issues`.* FROM `issues` WHERE `issues`.`parent_id` = 1  ORDER BY `issues`.`lft` ASC
--
481-
482-----==_mimepart_54df27595d37a_99d2913ed851659--
483-
484:   (146.6ms)  COMMIT
485-Redirected to http://192.168.11.11:7000/issues/8
486-Completed 302 Found in 832ms (ActiveRecord: 183.8ms)
487-

Etienne Massip wrote:

It seems okay to have 1 and 2 if the issue has no hierarchy, what do you expect ?

I have posted #14335#note-10.
As I described on it, Redmine 3.0 "lft" 1 and "rgt" 2 has no problem.