Defect #9331

Status list is sometimes missing values

Added by Frank Helk about 6 years ago. Updated about 4 years ago.

Status:ClosedStart date:2011-09-27
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Resolution:Invalid Affected version:1.2.0

Description

For some users the status listbox seems to omit some of the expected values.

Seems to appear with old, existing tickets as well when creating a new ticket. Problem dropped in when upgrading from 1.0.3 to 1.2.0.

The values are not missing in any case, I havn't figured out what exactly triggers that behaviour.

Snap_Workflow.png - Workflow definition for role (33 KB) Frank Helk, 2011-09-27 15:35

History

#1 Updated by Etienne Massip about 6 years ago

  • Status changed from New to Closed
  • Resolution set to Invalid

Guess that these statuses are not included in the workflows defined for your users role.

Please reopen if really needed.

#2 Updated by Mischa The Evil about 6 years ago

Two things that come in mind:
  1. Could it be related to workflow issues?
    For an example, see the FAQ
  2. Could it be related to the behaviour of the "Blocked by" issue-relations?
    If an issue is blocked by another issue that has an open status, then statues which are configured to behave as closed issue statuses are rejected from the status-list.
    For more details about the implementation of this feature see issues #1740, #2132 and revision r2800.

#3 Updated by Frank Helk about 6 years ago

Sorry for not being precise ... the stati are indeed allowed for that role - see attached snapshots. To be precise, that role can change change the status from every value to any other one.

I would show the list with the missing values, too, but I could not reproduce the problem right now.

But definitely seen: At least the entry for "Zugewiesen" (=assigned) was missing.

#4 Updated by Frank Helk about 6 years ago

First: Thanks for the tip ... the missing status values were blocked by a "related to" link. Breaking up that link solved the issue.

But that popped up another: I thought that the "related to" relationship only implies a "reference" that doesn't involve any restrictions like "blocked by" or "follows" would impose. Is that behaviour intended for the "related to" relationship ?

#5 Updated by Mischa The Evil about 6 years ago

Frank Helk wrote:

First: Thanks for the tip ... the missing status values were blocked by a "related to" link. Breaking up that link solved the issue.

That seems utterly strange...:/

Frank Helk wrote:

But that popped up another: I thought that the "related to" relationship only implies a "reference" that doesn't involve any restrictions like "blocked by" or "follows" would impose. Is that behaviour intended for the "related to" relationship ?

You're right. The "related to" relationship should not trigger any restrictions AFAIK.
I've just tried to reproduce this behaviour on source:/trunk@7623 and haven't been able to do so succesfully. Thus, so far, I'd say that the "related to" relationship also does not trigger any restrictions in general and logically that the issue you were experiencing should be classified as an exception.

The above leads me automatically to the following question: are you (still) able to reproduce this error? And, if yes, could you provide more information about you Redmine stack and configuration (see Submissions)?

#6 Updated by Frank Helk about 6 years ago

Mischa The Evil wrote:

You're right. The "related to" relationship should not trigger any restrictions AFAIK.

OK - good to know that we're on the same line ...

I've just tried to reproduce this behaviour on source:/trunk@7623 and haven't been able to do so succesfully. Thus, so far, I'd say that the "related to" relationship also does not trigger any restrictions in general and logically that the issue you were experiencing should be classified as an exception.
The above leads me automatically to the following question: are you (still) able to reproduce this error?

I've just tried it and I were not able to reproduce it ... so we might file that as exception. And I will keep an eye on it.

Unfortunately the creation and deletion of ticket relations seems not to be part of the ticket history, so I can't track that part precisely in the offending ticket. The only thing I can say ist that this ticket is kind of old, supposed to be created under Redmine 0.8.7 (My update path that far is 0.8.7 -> 1.0.1 -> 1.0.3 -> 1.2.0).

Since you've asked:

  • Redmine 1.2.0
  • ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]
  • MySQL 5.1.37
  • LOCAL GEMS

actionmailer (2.3.11, 2.3.5, 2.2.2)

actionpack (2.3.11, 2.3.5, 2.2.2)
activerecord (2.3.11, 2.3.5, 2.2.2)
activeresource (2.3.11, 2.3.5, 2.2.2)
activesupport (2.3.11, 2.3.5, 2.2.2)
fxri (0.3.6)
fxruby (1.6.16 x86-mswin32-60)
hpricot (0.6.164 mswin32)
i18n (0.4.2)
log4r (1.0.5)
mysql (2.8.1 x86-mswin32)
ptools (1.1.6)
rack (1.1.1, 1.0.1)
rails (2.3.11)
rake (0.8.7, 0.8.1)
ruby-opengl (0.60.0 i386-mswin32)
test-unit (2.0.1)
win32-api (1.2.1 x86-mswin32-60, 1.2.0 x86-mswin32-60)
win32-clipboard (0.4.4)
win32-dir (0.3.2)
win32-eventlog (0.5.0)
win32-file (0.5.5)
win32-file-stat (1.3.1)
win32-process (0.5.9)
win32-sapi (0.1.4)
win32-sound (0.4.1)
windows-api (0.2.4)
windows-pr (0.9.3)

#7 Updated by Mischa The Evil about 6 years ago

  • Status changed from Reopened to Closed
  • Resolution changed from Invalid to Cant reproduce

Please re-open if the issue re-occurs.

#8 Updated by José Campos over 5 years ago

  • Status changed from Closed to Reopened

This issue occurred to me too. The Closed status is missing in only one of our issues, and the user role can do pretty any change in status for this tracker. The issue does have two related issues (I haven't tried to delete the relation, though).

---
mysql Ver 14.14 Distrib 5.1.49, for debian-linux-gnu (x86_64) using readline 6.1
ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]
rails (3.2.6)
Redmine 2.0.3.devel.10153

#9 Updated by José Campos over 5 years ago

Sorry, my (BIG) mistake. I had a blocking issue. You can close this issue again. Sorry for the mistake.

#10 Updated by Mischa The Evil about 4 years ago

  • Status changed from Reopened to Closed
  • Resolution changed from Cant reproduce to Invalid

Also available in: Atom PDF