Project

General

Profile

Actions

Defect #13250

open

Status change refresh problem - cannot write fileds writeable in a given statatus

Added by Sándor Dombora about 11 years ago. Updated almost 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Issues permissions
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Affected version:

Description

The problem: cannot write fields writeable

Example:
We have users Martin, John and Steve
We have the following statuses: "new", "to be approved", "in progress", "to be tested", "resolved"
We have some fields: A
Matin can add new issues, and change status to "to be approved". He can change the issue and its content until John approves it i.e. places the issue to status "in progress".
John can approve issues, so changes status from "to be approved" to "in progress".
Steve gets the issue in status "in progress" and can place it in status "to be tested".
Only John has write access to the field A in status "to be approved" as it is connected to the approval of the issue. He should not have access the issue, he approved it as the work begins on the issue.

1. Martin adds a new issue and set the status to "to be approved"
2. John approves the task, would place a values in filed A.
3. By placing the issue in status "in progress" the field "A" becomes read only, so he cannot place value in it.

Environment:
Redmine version 2.2.1.stable
Ruby version 1.8.7 (x86_64-linux)
Rails version 3.2.11
Environment production
Database adapter PostgreSQL
Redmine plugins:
no plugin installed


Related issues

Related to Redmine - Defect #13172: Changing assignee then tracker or status reverts unsaved assignee change (during issue edit/update)Confirmed

Actions
Actions #1

Updated by Etienne Massip about 11 years ago

How is your workflow configured?

Actions #2

Updated by Sándor Dombora about 11 years ago

The workflow is huge, so I am going to write here only those parts which are relevant to the issue.

There problem occures because we apply high security settings.
For example. The developer gets the issue in Assigned status, when he starts the work on it changes the status to In progress.
These two statuses are reserved to developers noone can change attributes of the issue, only comments are allowed.
When the develper finishes his work, changes the status to Testing and fills in the Solution field. This is the place where one of the problems occur, because the Solution field is read only for all others, and the olny status when the Solutions field is writable is "In progress", otherwise the developer could change the solution - during the testing phase which should not occur.

The configuration for this scenario:

Developer role:
- can change issue status
- from Assigned to In progress
- from In progress to Testing
- from In pfogress to Ask for information
- write custom field Solution while the issue is In progress status
- if we allow deveeloper to update the Soultion field while the issue is in Testing status, he could change the Solution field during testing phase

The problem is, when the issue status is changed on the form, the Solution field is hidden, and it is not saved.
However in In progress status this field shod be writeable for the developer.

I understand the other side of the problem, when there are required fields in Testing phase - these shoud be filled in befors placing the issue to Testing, but there are again security issues - to enable writing of fields, which are supposed to be read only in other statuses, for different roles.

Best regards,
Sándor, ITIL Expert, CISA, CISM

P.S. I see a lot of things to be done on database side of the project (a lot of constraints to be added - which provides more security - I could help in this part of the development). Because Redmine is a great product I'd like to help its improvement.

Actions #3

Updated by Sándor Dombora about 11 years ago

Are there any news regarding this issue?

Actions #4

Updated by @ go2null about 8 years ago

The issue is that changing the status applies the new status, which it should not do as the new status is just a change, like any other other change done.

That is the new status permissions should NOT be enforced/triggered when in the input form.

Duplicate issue: Defect #13172

Actions #5

Updated by Toshi MARUYAMA almost 8 years ago

  • Related to Defect #13172: Changing assignee then tracker or status reverts unsaved assignee change (during issue edit/update) added
Actions #6

Updated by Toshi MARUYAMA almost 8 years ago

  • Description updated (diff)
Actions

Also available in: Atom PDF