Defect #1517
closedTask #1503: Testing of the product (9.4.0)
Text in the Description field not saved in a role request concept
100%
Description
TC 82: Role request: creating a concept (for oneself)
https://kiwi.czechidm.com/case/82/
@affected version 9.4.0
Two issues:
Unlike when I send off a request and the text in the Description field is saved, by hitting the Go back button and creating just a concept - having filled in the Description field - the text is NOT retained in the saved concept (even though I kept the obligatory sequence of first selecting the desired roles, and then typing in the text). It should behave in the same way.
And speaking of the field, would it be possible to simply move the Description field BELOW the list of roles (at the bottom of the form that is), so that the user KNOWS that they should fill this field only after adding the role(s)?
Updated by Radek Tomiška almost 6 years ago
- Description updated (diff)
- Category changed from 20 to Roles
- Assignee changed from Radek Tomiška to Vít Švanda
- Target version deleted (
Opal (9.4.0))
Updated by Vít Švanda almost 6 years ago
- Status changed from New to In Progress
- Assignee changed from Vít Švanda to milus kotisova
This is standard behavior: If you fill "Note" on identity detail and you click on the back button, then note will be also not saved. In the past was on the detail of request save button, but some users was confused (they wont send request not only save it).
I agree, the current state is confused too. I can add save button again.
Second problem is similar, but can be solved (prevent clear of description after some concept-role was added). Your idea with move description field is interesting too.
Updated by milus kotisova almost 6 years ago
Vít Švanda wrote:
This is standard behavior: If you fill "Note" on identity detail and you click on the back button, then note will be also not saved. In the past was on the detail of request save button, but some users was confused (they wont send request not only save it).
Not quite true, the roles ARE saved, after all, when using the Go back link on the request form. Why not the text then?
I agree, the current state is confused too. I can add save button again.
I think we can add a green or black link (just like the "Go back" link now) Save as a concept
Second problem is similar, but can be solved (prevent clear of description after some concept-role was added). Your idea with move description field is interesting too.
Thank you.
Updated by milus kotisova almost 6 years ago
- Assignee changed from milus kotisova to Vít Švanda
Updated by Vít Švanda almost 6 years ago
Not quite true, the roles ARE saved, after all, when using the Go back link on the request form. Why not the text then?
- This behavior is again standard, because request is one entity and concept-role is different. One request can have multiple concept-roles. So the concept-role is saved separatley, it is same as detail of identity and their contracts.
Updated by milus kotisova almost 6 years ago
I don't think that it is a good practice to have a user fill in something and - then it is dropped without any warning.
As a minimum, the user should be informed that by saving a concept, they are going to lose the text. Because it is inconsistent to save only part of the input from the form :-).
Updated by Radek Tomiška almost 6 years ago
We agree, this feature can be implemented, we speak about it long time, but it is a different story :)
Updated by Vít Švanda almost 6 years ago
- Status changed from In Progress to Needs feedback
- Assignee changed from Vít Švanda to Radek Tomiška
- Target version set to Pyrite (9.5.0)
I again added separately button for save of request.
Updated by Radek Tomiška almost 6 years ago
- Status changed from Needs feedback to Resolved
- Assignee changed from Radek Tomiška to Vít Švanda
- % Done changed from 0 to 100
I did test and review, save button works as before, thx!
I've added success message only, after save is executed:
https://github.com/bcvsolutions/CzechIdMng/commit/2325733ad027df9a9c220e83b777249abc1a59f3
Updated by Vít Švanda almost 6 years ago
- Status changed from Resolved to Closed