Hi,

None-the-less we ARE using  the valid patch doc "op" values of "add" and "remove" to manage users in roles for a given record. It would be a hack for us to accept a patch doc on a controller end-point like:

 

But then submit it to the Change Log Service as a LogLinkCommand just to workaround the fussy validation you have.

Furthermore, even if THIS example could be done via such a hack, what if some consuming application had the business requirement of a property on a model which is a string array containing a list of "colors", for example. A suitable patch doc for adding a new colour to the array might be:

 

Now it is, surely, inappropriate to expect such an application to "log" this as a "LINK" (between an Audit and a "color"?) just so that it can be accepted by your service?

Or, what if we want to allow our service to accept the (valid) patch doc "op" of "copy" such as:

 

We would just want to log this with your service using a "LogUpdateCommand" but, again, you would currently reject it because it is not a "replace".

In summary, I can only repeat, it is not  your remit to control how the consuming services make use of patch docs. Your service should, I believe, just store whatever patch doc the consumer would like logged.

Please can you remove the validation which only accepts "replace" so that we can use this in Arc?

Thanks.

Gary.

________________________________________
 
Gary Freer



Senior Software Engineer



 





    
From: Tat Yoong Law <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Sent: Thursday, April 25, 2024 8:42 AM
To: Gary Freer <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Anthony Wong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Mah Jin-Khai <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Hon Kuan Yong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; SueAnn See <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Lim Wai Kheong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Lim Zhao Siang <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Keith Low <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Yip Fan Wong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Ping Ping Lau <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Duraid Wadie <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Cc: Joe Glenn <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Joshua Haseldine <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Nigel Surridge <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Subject: RE: Using the LogUpdateCommand of the Change Log Service 
 
To be honest, I also feel this kind of action more like a link and unlink rather than an update. @Gary Freer, may I know what is the concern from your side of using LogLinkUnlinkCommand instead of LogUpdateCommand to capture the audit trail?
 
LogLinkUnlinkCommand | ICSA 3.0 Changelog (stoplight.io)
 
Thanks.
 
 
 
Tat Yoong Law



Software Development Team Leader



 





    
From: Gary Freer <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Sent: Thursday, April 25, 2024 2:57 PM
To: Anthony Wong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Mah Jin-Khai <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Tat Yoong Law <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Hon Kuan Yong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; SueAnn See <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Lim Wai Kheong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Lim Zhao Siang <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Keith Low <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Yip Fan Wong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Ping Ping Lau <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Duraid Wadie <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Cc: Joe Glenn <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Joshua Haseldine <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Nigel Surridge <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Subject: Re: Using the LogUpdateCommand of the Change Log Service
 
Hi,
 
No, we're using patch documents for the management of users in each role for a given record. The API end-points expect requests like this (usually containing multiple add/removes):
 
 
 
This is entirely within the patch doc standards: https://jsonpatch.com/
 
This then gets applied to the model and, if successful, I need to write it to the audit trail so it can be displayed like any other change later.
 
The only problem I am facing is that when I send this patch doc off as the "changes" on a LogUpdateCommand to your Change Log Service it rejects it because you have a (unnecessary) validation which was the the "op" value must always be "replace". But, in my opinion, it is not  your remit to control how the consuming services make use of patch docs. You should just log whatever we ask you to log and then return it back to us when we query later.
 
We are already waiting for a fix to the fact that you don't allow the "value" (or "oldValue") to be NULL (both of which are perfectly reasonable when you are clearing (or first setting) a property) and for a fix to the poor performance we are observing when querying from a database with a large (but realistic) set of data so this new issue is now a third reason why we can't release a version of Arc which has an audit trail feature. If all of these things cannot be fixed in a short period of time I'll have to go back to the Arc Product Manager and think again about how we implement audit trail in Arc.
 
Thanks,
 
Gary.
 
 
________________________________________
 
Gary Freer



Senior Software Engineer



 





    
From: Anthony Wong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Sent: Thursday, April 25, 2024 6:38 AM
To: Mah Jin-Khai <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Gary Freer <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Tat Yoong Law <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Hon Kuan Yong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; SueAnn See <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Lim Wai Kheong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Lim Zhao Siang <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Keith Low <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Yip Fan Wong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Ping Ping Lau <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Duraid Wadie <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Cc: Joe Glenn <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Joshua Haseldine <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Nigel Surridge <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Subject: RE: Using the LogUpdateCommand of the Change Log Service
 
Adding @Duraid Wadie to the loop.
 
Hi Gary,
 
After a discussion with the team, we think the scenario you are trying to achieve is more like a link and unlink command based on the example you’ve given. i.e. linking a user to a role, unlinking a user from a role. Can you use LINK/UNLINK command instead of UPDATE commands?
 
Thanks,
 
<PRESIDIO_ANONYMIZED_PERSON>
 
 
 
Anthony Wong



Software Development Team Leader



 





    
From: Anthony Wong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Sent: Wednesday, April 24, 2024 6:45 PM
To: Mah Jin-Khai <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Gary Freer <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Tat Yoong Law <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Hon Kuan Yong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; SueAnn See <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Lim Wai Kheong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Lim Zhao Siang <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Keith Low <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Yip Fan Wong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Ping Ping Lau <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Cc: Joe Glenn <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Joshua Haseldine <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Nigel Surridge <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Subject: RE: Using the LogUpdateCommand of the Change Log Service
 
Adding @Ping Ping Lau to the loop
 
 
Anthony Wong



Software Development Team Leader



 





    
From: Mah Jin-Khai <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Sent: Wednesday, April 24, 2024 5:03 PM
To: Gary Freer <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Tat Yoong Law <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Anthony Wong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Hon Kuan Yong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; SueAnn See <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Lim Wai Kheong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Lim Zhao Siang <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Keith Low <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Yip Fan Wong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Cc: Joe Glenn <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Joshua Haseldine <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Nigel Surridge <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Subject: RE: Using the LogUpdateCommand of the Change Log Service
 
Include @SueAnn See @Lim Wai Kheong @Lim Zhao Siang @Keith Low @Yip Fan Wong.
 
Can someone take a look at below?
 
JK.
 
 
Mah Jin-Khai



Head of Software Development



 





    
From: Gary Freer <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Sent: Wednesday, April 24, 2024 3:44 PM
To: Tat Yoong Law <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Anthony Wong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Hon Kuan Yong <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Cc: Joe Glenn <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Joshua Haseldine <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Mah Jin-Khai <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>; Nigel Surridge <<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>>
Subject: Using the LogUpdateCommand of the Change Log Service
 
Hi guys,
 
Not sure who is the best person to direct this question to so I am hoping one of you can help. Please advise if there is someone else better placed.
 
In Arc we are consuming the Change Log Service and referring to the Stoplight documentation: https://ideagen.stoplight.io/docs/icsa-changelog-gen2-apidoc/fe9dcdbd21ebd-log-update-command
 
This page suggests that for each change the "op" value must be set to "replace" (else, presumably, it will be rejected by the service and sent to the DQL).
 
However in Arc, under some circumstances, we are using the "add" and "remove" operation in patch docs (when modifying an array) so may have a body like:
 
"changes": [
            {
                  "op": "add",
                  "path": "/roles/11",
                  "value": {
                        "id": 45,
                        "guid": "056b256b-d479-417e-a8fc-e2bf25f5ae7c",
                        "name": "En Hui Audrey Polat"
                  }
            }
      ]
 
Now, I already know that until recently you had a bug which would reject this command because the "oldValue" is null (fixed in CCLS-822 I hope) but my question is: even if we update the version of the change log service we are using to 1.3 (to get that bug fix) will my command still get rejected because of my use of "add" (or "remove") as the "op"?
 
If so, can you please make the change to accept other "op" values? I don't think the change log service should really be applying any validation here. As long as the patch doc is well-formed it should just log whatever the consuming app is asking it to log - it is not the change logs responsibility to limit how consuming apps use patch docs.
 
Please let me know what you think. This is fairly urgent to us in Arc because at present not all of the changes being made by our users are going into the change log and, therefore, the audit trail is incomplete.
 
Thanks,
 
Gary.
 
 
<PRESIDIO_ANONYMIZED_PERSON>



Senior Software Engineer



 Based on Gary's email, most likely he is going to use logUpdate instead of linkUnlink command for linking a user to the existing role. If we were to allow that to happen, we will end up having different command type for a link/unlink action. My only concern is that will have impact on the centralized UI design later as we allow products to store changelog data differently for the similar action.
2 Like reactions.
2
Begin Reference, I have added the validatio... by Tat Yoong Law
Tat Yoong Law
11:59 AM
Ping Ping Lau
4/26/2024, 1:48 PM
I have added the validation rule in this page https://ideagen.atlassian.net/wiki/spaces/SSD/pages/edit-v2/39135380419. Please scroll to this section 📷
I have a concern on removing the mandatory validation for oldValue and value. If we do not have that, what if products did a mistake and that's it we are not able to captured any audit trails for any records update. I would suggest we better keep it for replace op.
1 Like reaction.
1
Begin Reference, I have a concern on removi... by SueAnn See
SueAnn See
12:01 PM
Tat Yoong Law
4/29/2024, 11:59 AM
I have a concern on removing the mandatory validation for oldValue and value. If we do not have that, what if products did a mistake and that's it we are not able to captured any audit trails for any records update. I would suggest we better keep it for replace op.
actually i have a similar concern for add /remove too. If one product decided to use oldValue and value opposite/different to general expectations, that would mean the audit trail will look inconsistent. e.g. some products having values/some not for the same type of action.
Yes, if the retrieval part only on the prod... by Tat Yoong Law
Tat Yoong Law
12:04 PM
Edited
Yes, if the retrieval part only on the products side, I think we are still ok as it leaves it to them to retrieve and display as they want even they don't follow changelog "standards". It's all up to them but if we have a plan to have centralized UI, it all matters then. 
perhaps the decision will need to be on wha... by SueAnn See
SueAnn See
12:35 PM
Edited
perhaps the decision will need to be on what we can afford to do now vs later due to the main concerns from ARC being timeline related.
1 Like reaction.
1
has context menu
Compose
Ping Ping Lau is out of office and may not respond



You are an expert in software architecting. Review the email trail above and the comments given by other team members. 

What is your comments and opinion.