Feature #8437
closed
Added by Evgeny Novikov over 6 years ago.
Updated almost 6 years ago.
Description
A long ago I assumed that we will have a lot of job classes for various types of target programs, and for each such class Bridge should provide specific means for setting corresponding verification jobs and for visualization of their verification results. The former won't be most likely implemented ever. For the latter we suppose to use specific visualization for specific data reports, i.e. information how to treat data reports should be incorporated within them rather than to come from knowledge of job classes or component names.
Files
- % Done changed from 0 to 100
- Due date set to 12/14/2017
- Status changed from New to Resolved
Implemented in branch "feature_8437".
But how did you overcome former bindings of job classes with, say, comparison attributes and specific data report visualization? As far as I understand, you need some additional knowledge from Core to make things working as it was before.
Evgeny Novikov wrote:
But how did you overcome former bindings of job classes with, say, comparison attributes and specific data report visualization? As far as I understand, you need some additional knowledge from Core to make things working as it was before.
Comparison attributes are the same now for both classes and reports can be compared even if some attributes are not found. Data report visualization depends on data format. See comment in ReportData.html leading to function where format is checked.
- Blocks Feature #8648: Allow to download/upload job subtrees added
- Target version changed from 2.0 to 1.0
This issue was implemented together with issues for Klever 1.0.
Ilja noticed a bug (see the attached screenshot) that is most likely related with this feature implementation. But perhaps the issue is in Core which doesn't report some required data in advance.
Evgeny Novikov wrote:
Ilja noticed a bug (see the attached screenshot) that is most likely related with this feature implementation. But perhaps the issue is in Core which doesn't report some required data in advance.
The problem is with data. For non-validation jobs "before fix" key is pointless as "after fix" doesn't exist. So the format should be like this:
{<key>: {'ideal verdict': <val>, 'verdict': <val>, 'comment': <val>}}
Comment here is not required. You can change this behavior in reports.utils.ReportData.__get_type().
- Status changed from Open to Resolved
Vladimir Gratinskiy wrote:
Evgeny Novikov wrote:
Ilja noticed a bug (see the attached screenshot) that is most likely related with this feature implementation. But perhaps the issue is in Core which doesn't report some required data in advance.
The problem is with data. For non-validation jobs "before fix" key is pointless as "after fix" doesn't exist. So the format should be like this:
{<key>: {'ideal verdict': <val>, 'verdict': <val>, 'comment': <val>}}
Comment here is not required. You can change this behavior in reports.utils.ReportData.__get_type().
Actually, for validation for any row in the table there may be either "before fix" or "after fix" or they both, why not?.. During deciding a validation job table cells are fulfilled step by step. But even after finishing a validation job decision there still can be empty cells. I fixed the mentioned function appropriately in 8d59ad69 to branch new-report-data.
BTW, this all is a first step towards #8436. When it will be implemented we will have another way to visualize various verification results.
- Status changed from Resolved to Open
An unexpected consequence is that I couldn't upload any verification job archive without specifying parent identifier. I hope that this can be trivially fixed.
Evgeny Novikov wrote:
An unexpected consequence is that I couldn't upload any verification job archive without specifying parent identifier. I hope that this can be trivially fixed.
Ditto for archives of verification job trees.
Evgeny Novikov wrote:
Evgeny Novikov wrote:
An unexpected consequence is that I couldn't upload any verification job archive without specifying parent identifier. I hope that this can be trivially fixed.
Ditto for archives of verification job trees.
Fixed.
- Status changed from Open to Resolved
Works perfectly for archives of both jobs and job trees. I could even move verification jobs to the root level when editing them.
- Status changed from Resolved to Closed
I merged the branch to master in 4339da97 as a part of branch core-new-formats.
- Related to Bug #8980: Jobs comparison is broken added
Also available in: Atom
PDF
