Bug 996944 - GDT Audit log: missing information in column update logs
GDT Audit log: missing information in column update logs
Status: VERIFIED
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
6.0.0
Unspecified Unspecified
medium Severity medium
: ER3
: 6.1.0
Assigned To: manstis
Lukáš Petrovický
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-14 06:38 EDT by Zuzana Krejčová
Modified: 2016-07-31 21:14 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Zuzana Krejčová 2013-08-14 06:38:43 EDT
Description of problem:
The only information shown about what was updated in the column concerns the column header, the field of the fact pattern used and the operator. If you change anything else (that is actually caught, see bug 996932), the information is missing. 
An example: change of the fact pattern or setting the (optional) value list.


Version-Release number of selected component (if applicable):
kie-wb 6.0 CR1
Comment 5 Roger Martínez 2013-11-08 06:25:36 EST
Fixed.

Audit log - Detected all changes in column definition.

Created a DiffColumn interface which all columns implements, so the logic is contained in same column implementaion, as this logic is used in seveeral core points. 

The audit log uses the DiffColumn#diff method to detect all changes. The UI has been modified too.

Commits on master
=================
- https://github.com/droolsjbpm/drools/commit/cb11699b35d9437fc33ff6019b48bf5fba560ac1

- https://github.com/droolsjbpm/drools-wb/commit/05686a518f6e0ad9877ba66f73b5c99f8e92749b

Commits on 6.0.X
================
- https://github.com/droolsjbpm/drools/commit/7d6ee1550e76dba8082545a8131250fb49b559a2

- https://github.com/droolsjbpm/drools-wb/commit/2f792b130edb0ed512b1176fbd1f407395fdba54
Comment 6 Roger Martínez 2013-11-08 06:26:57 EST
I have reviewed the implementation and backwards compatibility for the serialized audit log with Mike Anstis too.
Comment 7 Zuzana Krejčová 2013-12-10 12:06:20 EST
Updates without information about changed field (just timestamp with author and which column was updated):
- pattern (condition column)
- update engine (set the value of a field)
- everything used with attributes, metadata (there's just 'hide column') and 'delete an existing fact' action column

Incorrect information:
- calculation type (condition column) - values user selects are 'Literal value', 'Formula', 'Predicate'; values Audit log shows are: 1, 3, 5
- fact (set the value of a field) - user chooses value for field 'fact', Audit log shows field labelled 'Bound Variable'
- metadata - Audit log shows: Updated column 'null'

(incorrectly posted in bug 996932 comment 8)

We're halfway there!
Comment 8 Roger Martínez 2014-01-09 17:10:14 EST
Hi Zuzana,

First of all sorry for the delay with this issue... there were another critical ones to fix previously.

You were right, the updates you comment were not caught.

I have implemented all missing updates and testes with all atributes and columns, so I hope that this BZ will can be closed and verified this time! :)


Commits master
**************
- https://github.com/droolsjbpm/drools/commit/80fe2cd7d130d9926ea6f101078e62275ce30f14

- https://github.com/droolsjbpm/drools-wb/commit/3f3a50cc103fee8e12e65a47091c0a16b5bf74c1


(In reply to Zuzana Krejčová from comment #7)
> Updates without information about changed field (just timestamp with author
> and which column was updated):
> - pattern (condition column)
> - update engine (set the value of a field)
> - everything used with attributes, metadata (there's just 'hide column') and
> 'delete an existing fact' action column
> 
> Incorrect information:
> - calculation type (condition column) - values user selects are 'Literal
> value', 'Formula', 'Predicate'; values Audit log shows are: 1, 3, 5
> - fact (set the value of a field) - user chooses value for field 'fact',
> Audit log shows field labelled 'Bound Variable'
> - metadata - Audit log shows: Updated column 'null'
> 
> (incorrectly posted in bug 996932 comment 8)
> 
> We're halfway there!
Comment 9 Zuzana Krejčová 2014-01-27 06:48:56 EST
It looks like these commits didn't make it into the product.
Comment 11 Edson Tirelli 2014-01-27 09:41:28 EST
Roger, your comment only lists commits on master. Were they cherry-picked to 6.0.x? Can you please list them if so?
Comment 12 Roger Martínez 2014-01-27 17:45:29 EST
Hi Edson,

Sure! Sorry about that.. I forgot some cherry-picks.

Tomorrow morning I will cherry pick them! Thanks

(In reply to Edson Tirelli from comment #11)
> Roger, your comment only lists commits on master. Were they cherry-picked to
> 6.0.x? Can you please list them if so?
Comment 14 Zuzana Krejčová 2014-01-29 05:03:18 EST
With CR2, I also found that changing the field of an action-insert column ('Set the value of a field on a new fact') produces audit log entry with 'Fact type' instead of 'field' as the updated part.
Could you fix that as well, please?
Comment 15 Roger Martínez 2014-01-29 16:59:30 EST
Hi Zuzana!

Good testing! :)

Sorry for the inconvenience... there are so many fields and I thought I had tested all of them... :-S

I have commited the changes:

- (master) https://github.com/droolsjbpm/drools-wb/commit/39655480ec49ec9b45c725c5969af7bb31cac788

- (6.0.x) https://github.com/droolsjbpm/drools-wb/commit/26d7dbf7d01d411d611921be9b824d0552d89bb4

Thanks!


(In reply to Zuzana Krejčová from comment #14)
> With CR2, I also found that changing the field of an action-insert column
> ('Set the value of a field on a new fact') produces audit log entry with
> 'Fact type' instead of 'field' as the updated part.
> Could you fix that as well, please?
Comment 16 Lukáš Petrovický 2014-02-07 11:19:15 EST
This no longer has a target release of 6.0.0.
Comment 17 Zuzana Krejčová 2014-02-21 10:36:39 EST
A few more things...

Metadata column updates are incorrectly listed as "Updated Action column '<metadata_column_name>'".

If I change a condition column pattern, the event is listed but the information about the change is missing. E.g. if I have column with pattern Person [p1], change the pattern to Person [p2] and leave the rest as it was before (so I just change the pattern binding), the audit log contains an entry like this:
Column updated.
On 21-Feb-2014 04:28:32 by testadmin.
Updated Condition column 'PersonAge'

'Delete an existing fact' action column updates are caught but there is no information about what was changed.
Comment 18 Roger Martínez 2014-02-21 12:46:33 EST
Hi Zuzana,

Fixed all three issues.

About the second one (changing a condition column pattern), I have only reproduced it by adding a new pattern on edit time, but fixed too.

Commit in 6.0.x -> https://github.com/droolsjbpm/drools-wb/commit/ed93539558e91a1fe0f12abb74e3ac5553607db9

Commit in master -> https://github.com/droolsjbpm/drools-wb/commit/d03abb5c8f9118d7d762146dd51ff9ec74f89c58

Thanks
Comment 19 Zuzana Krejčová 2014-03-19 08:44:08 EDT
'Delete an existing fact': column header change information is still missing.

For dialect attribute - changing the dialect default value from mvel to java seems okay, but the other way around, java to mvel, the update is caught but the information about the exact change is missing.


And a few details:
I'm not sure if the following is wrong, so just to note, for this action column, the log entry now says "Updated column .." instead of "Updated Action column ..".

When changing operator in a condition column, there is a "typo", two double dots - "Operator::".

For date values - user enters dd-MMM-yyyy format but the log entry contains something like 'Wed Mar 19 13:32:10 GMT+100 2014'. Which is technically correct, as far as the date is concerned, but using the same format would be preferable.
Comment 20 Zuzana Krejčová 2014-03-25 05:15:05 EDT
After further testing, these updates are also caught but information is missing (log entry only says 'Updated column <header>.' ):
- BRL fragment columns (both condition and action): 
    - changing the header
    - changing the code of the BRL fragment
- Execute Work Item:
    - change of the Work Item
    - change of input parameters
    - changing the header
- Set field using a Work Item:
    - changing the Work Item (result parameter)
The last one will probably be an issue with the 'Set field using a Work Item on a new Fact' as well - testing is currently blocked by bug 1079988.


BRL fragment columns and Execute Work Item column also don't have the column type specified - the log entry says 'Updated column ...' instead of 'Updated Action/Condition column ...' as is now usual.

Sorry for feeding this to you bit by bit - there is just too much to test.
Comment 22 Zuzana Krejčová 2014-04-23 05:45:22 EDT
Just a note, for column 'Set field using a Work Item on a new Fact', information is missing for these updates (log entry only says 'Updated column <header>.'):
- changing the Work Item (result parameter)
- changing the (fact) pattern
Comment 25 manstis 2014-06-20 08:19:45 EDT
Hello,

This BZ is quite a few separate requirements. I have fixed the outstanding items listed in comment#19, comment#20 and comment#22 *EXCEPT FOR* BRL Fragments (the comparison of which to build an Audit Log Entry is reasonably involved). 

My proposal is to open a new BZ just for the BRL Fragments and close this BZ for all the other smaller issues. That way we get a lot of the fixes into 6.1 and can track the BRL Fragment requirement without confusion from the other items in this BZ.

What do you think?

Thanks,

Mike
Comment 26 Zuzana Krejčová 2014-06-20 08:38:19 EDT
(In reply to manstis from comment #25)
> Hello,
> 
> This BZ is quite a few separate requirements. I have fixed the outstanding
> items listed in comment#19, comment#20 and comment#22 *EXCEPT FOR* BRL
> Fragments (the comparison of which to build an Audit Log Entry is reasonably
> involved). 
> 
> My proposal is to open a new BZ just for the BRL Fragments and close this BZ
> for all the other smaller issues. That way we get a lot of the fixes into
> 6.1 and can track the BRL Fragment requirement without confusion from the
> other items in this BZ.
> 
> What do you think?
> 
> Thanks,
> 
> Mike

Sure, see (newly created) bug 1111583. You can disregard BRL fragments for this BZ.
Comment 27 Zuzana Krejčová 2014-09-26 09:07:24 EDT
'Delete an existing fact': column header change information is still missing.
If I change the header e.g. from 'delete' to 'delete2', I get only this in the audit log:
Column updated.
On 25-Sep-2014 by testadmin.
Updated column 'delete2'

'Execute Work Item' - change of input parameters: update does not contain parameter names, just values.
If you use a Work Item with parameters 'param1' with value 'val1' and 'param2' with value 'val2' and change both parameter values at once, the update will contain only the change values, but will not indicate which value belongs to which parameter:
Column updated.
On 25-Sep-2014 by testadmin.
Updated Action column 'executeWI'
    Work Item Parameter Value: '"val1"' » '"val3"' 
    Work Item Parameter Value: '"val2"' » '"val4"'
   
'Execute Work Item' - change of the Work Item: this update, on the other hand, contains redundant info - about both WI name and WI display name. Since the user sets only the Work Item itself, mentions of both name and display name may be a bit confusing.

'Set field using a Work Item on a new Fact' - changing the fact pattern: update contains the last Work Item change as well, even if this wasn't change in this update.
(Change the WI, check the audit log. There is a log entry with the WI update. Change the fact pattern, check the audit log again. There is the previous log entry and a new one, containing the fact pattern update and the same WI update as the previous entry.)
Comment 29 manstis 2014-11-24 11:13:14 EST
Regarding this:

> 'Set field using a Work Item on a new Fact' - changing the fact pattern: update
> contains the last Work Item change as well, even if this wasn't change in this > update.
> (Change the WI, check the audit log. There is a log entry with the WI update. 
> Change the fact pattern, check the audit log again. There is the previous log 
> entry and a new one, containing the fact pattern update and the same WI update > as the previous entry.)

When you change the pattern the field and Work Item Return parameter are cleared - as the popup doesn't know what data-type the new pattern/field is (as no field has been selected) and hence cannot give a list of matching WID Return parameters. When you select a field the first WID with a return parameter matching the pattern/field is selected. This could be different to the original WID you had chosen before the pattern change.

This is what I observed when trying to replicate this issue. When you re-test can you please keep this in mind and advise if this was not the case (if so please provide more explicit steps to recreate this - last!?! - issue). Thanks.

Note You need to log in before you can comment on or make changes to this bug.