Navigation:
Primary changes are that buttons have the ability to perform an action as well as perform navigation functions. Example classification:
Other small changes include buttons that show / hide where you are to remove clutter:
- create new concept disappears on report views
- single button to return back to default editing view
Validation - Task View:
Report only shows concepts that are within the scope of the task (in other words the list is filtered by concepts in the review list).
Report also shows the concept FSN for easier identification
Concepts appear below the assertion error heading instead of having to toggle between the report and the header.
Check boxes unnecessary
Validation - Project View:
Report shows source author and task, and project for concepts in the list
Report also allows to select one or more concepts and create a task from them.
Merge - View:
Initial request was to have an ability to have a "merge review" similar to how we have concept reviews or a means to notify another author that their change was over written as a result of amerge conflict.. Discussed with Rory and he suggested this is not the best approach... will table the merge screen for our discussion.
primary desires are around using traceability service to show where the items in the merge report come from (author task project etc) to resolve a few issues that came up in release time when changes made were over written by other authors.
6 Comments
Yongsheng Gao
Thanks Ashley Hickey, validation report needs to support author moving issues into a whitelist. We need a button or tick box to do this. Then, these whitelisted concepts won't be displayed in the validation report anymore. Of course, as we discussed, the whitelisted concepts should be stored in the SCA for future reference.
Rory Davidson
Implementing whitelists is something we need to think carefully about doing before implementing, due to the potential issues this will create in the long term when things are mistakenly put on a whitelist and then ignored, ending up in possibly corrupt data in a release.
Yongsheng Gao
Agreed. It definitely needs careful design. The most import part will be determining what can be whitelisted. The errors should NOT be allowed for whitelist in particular those related to data integrity. The warning should be fine as the starting point.
We do need this function to avoid going through the whitelisted validation report again and again. They should be hidden and only available for audit or review if it is needed.
Rory Davidson
I would not hide them at all as this is potentially dangerous and not recommended. They were never whitelisted before, just not seen until the release.
However I would flag those that are whitelisted so it is easy to see them and then move on.
Toni Morrison
The presentation of the report to the authoring team needs careful consideration too and I see a few notes above related to the presentation. The known lack of FSN aside, the current report isn't very user-friendly.
I want to be able to quickly review the report and identify issues that I can/should fix.
I want things that cannot be corrected by the author and things that are whiltelisted and should not be fixed by the author to be easily identifiable and preferably separated from those issues that the author can/should address.
I want the messages that are returned to be stated in a way that I can easily identify the action that needs to be taken to resolve the issue.
Kai Kewley
I really like this notion of giving context to validation errors to support recognition and aid decision making rather than hiding anything. Thanks for your thoughts Toni.