Defect #9331
closedStatus list is sometimes missing values
Added by Frank Helk about 13 years ago. Updated about 11 years ago.
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.
Files
Snap_Workflow.png (33 KB) Snap_Workflow.png | Workflow definition for role | Frank Helk, 2011-09-27 15:35 |
Updated by Etienne Massip about 13 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.
Updated by Mischa The Evil about 13 years ago
- Could it be related to workflow issues?
For an example, see the FAQ - 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.
Updated by Frank Helk about 13 years ago
- File Snap_Workflow.png Snap_Workflow.png added
- Status changed from Closed to Reopened
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.
Updated by Frank Helk about 13 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 ?
Updated by Mischa The Evil about 13 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)?
Updated by Frank Helk about 13 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)
Updated by Mischa The Evil almost 13 years ago
- Status changed from Reopened to Closed
- Resolution changed from Invalid to Cant reproduce
Please re-open if the issue re-occurs.
Updated by José Campos over 12 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
Updated by José Campos over 12 years ago
Sorry, my (BIG) mistake. I had a blocking issue. You can close this issue again. Sorry for the mistake.
Updated by Mischa The Evil about 11 years ago
- Status changed from Reopened to Closed
- Resolution changed from Cant reproduce to Invalid