Add audit json logging design page

[mreynolds389]

Design doc created to continue discussion on a new JSON format for the audit log

[mreynolds389]

Friendly reminder this needs to be reviewed, thanks!

[vashirov]

LGTM

[droideck]

As discussed in the comments, if there are plans to make a date format configurable, I think it will be nice to describe the "configuration" part here, too.

It's a minor issue, though. The rest, LGTM.

[mreynolds389]

As discussed in the comments, if there are plans to make a date format configurable, I think it will be nice to describe the "configuration" part here, too.

It's a minor issue, though. The rest, LGTM.

Sorry I haven't pushed my recent changes. I'll do that shortly

[progier389]

Looks good

[progier389]

I wonder if the changetype is really usefull (it is a bit redundant with the operation parameter field name )

[mreynolds389]

I wonder if the changetype is really usefull (it is a bit redundant with the operation parameter field name )

Well I thought it might make parsing "easier" as you wouldn't have to check all the operation keys to see if they are set to determine what the operation is, but I agree it is redundant. I removed it.

I did some more JSON object cleanup around the modify operation (removed redundant "delete_value" and will just use "value" for all op types).

[mreynolds389]

I wonder if the changetype is really usefull (it is a bit redundant with the operation parameter field name )

Well I thought it might make parsing "easier" as you wouldn't have to check all the operation keys to see if they are set to determine what the operation is, but I agree it is redundant. I removed it.

Ok I know I just removed the changetype key, but I'm having second thoughts about it. I think there are benefits to making it easier to find the op key (especially for a parser writer). Thoughts?

[progier389]

Can you describe a case where having the changetype would really help ?
IMHO most application should use a json decoder library to avoid some nasty surprise with escaped characters
and such libraries provide way access/check the fields, (and checking if the field exist is always a good idea for robustness point of view)
BTW in python using if 'modify' in parsed_entry_log: is as simple as if parsed_entry_log['changetype'] == "modify':

[mreynolds389]

Can you describe a case where having the changetype would really help ? IMHO most application should use a json decoder library to avoid some nasty surprise with escaped characters and such libraries provide way access/check the fields, (and checking if the field exist is always a good idea for robustness point of view) BTW in python using if 'modify' in parsed_entry_log: is as simple as if parsed_entry_log['changetype'] == "modify':

I guess I'm looking at this from a REST perspective. When we set the "changetype" we are telling the parser the key. Otherwise the parser needs to know all the possible keys in advance. I know changetypes are not going to change, but I was thinking it would "slightly" simplify what a parser would need to do. But, this is not a REST API object so we can leave changetype out...