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.


You are an expert in software architecting. 

Analyse the above email  trails with regards to a reported "bug". Is the suggested Link/Unlink solution appropriate or what they want is the industry standard? let me know what you think.