Developer forum

Hi,

I've tried to update the field on product has mentioned above using edit form launched in different ways and was not able to catch the issue - proof. Please, have a look at the video and specify your scenario if it's actually different agaianst mine. Besides, your solution uses very old admin version, I suggest you to upgrade it to an existing later one to avoid buges fixed during the time.

BR, Oleg QA  

Hi Oleg,

Thanks for the response and for looking into this so quickly!  The customer site is on version 9.9.7 but shows the same behavior.  Here are the differences between my test and yours:

• I made edits in  ECOMMERCE -> Product catalog and not in the PIM.  I can not reproduce the behavior when editing from the PIM

• In some cases, the behavior only occurs the first time that a product is saved.
• It seems to be related to the product.  It is easily repeatable with apparel items but for bike pedals, it does not occur.
• You do not need to make a change for a change to be logged.  Open an apparel item in the Ecommerce Product catalog and select save.  The audit log will show a change to the color value.

The simplest way to reproduce is:

1. Select an apparel product in Ecommerce->Product catalog that has not been previously edited
2. Edit the Product
3. Select "Save and Close" without changing anything.
4. Check the Audit log from Settings->System->Audit

Hello Brian, 

For the 'Color' custom field you changed options values from Black\Blue\etc. to codes like #000000\#2196F3\etc.
But you didn't update products Color values and the values still are Black\Blue.. yes dynamicweb doesn't do it automatically when you are changing list option value.

you able to see such products using sql:
SELECT ProductId, Color FROM ecomproducts where Color <> '' AND Color not like '#%'

I would like to suggest to update this using this sql:
update ecomproducts set Color = fo.FieldOptionValue from ecomproducts p
join EcomFieldOption fo on p.Color = fo.FieldOptionName
join EcomProductField pf on fo.FieldOptionFieldId = pf.ProductFieldId
where pf.ProductFieldSystemName='Color' and p.Color <> '' and p.Color not like '#%'

Hi Alexander,

Thanks for the information.  The issue that I am trying to solve has to do with the Audit log showing changes that were not made by the user.  I was demonstrating the behavior using this test site but I don't really need to solve the problem with the color value.  The customer's site is more complicated so I was trying to demonstrate the problem with a site that is pretty close to a newly created Rapido site.  The customer's site shows this audit log entry whenever a product is saved, despite nothing being changed:

I have another example where a single change caused four separate entries in the audit log with multiple fields registered as being changed per entry:

You can view the audit log at: https://sandbox-dynamicweb.biolegend.com/

Hi Brain, 

I wanted to say that Audit compare raw data without doing something special.

So let's look your new site audit log: I will explain you what is going on on the product with id=15078 because after save it brings a lot of  audit records.

1) let's compare manualy text before save and after save for 'Usage' custom field, you can recive row data using this sql query:

select * from AuditDetail where AuditDetailAuditId=61 and auditdetailid=214 

let's compare(I've higlighted differences) AUDITDETAILVALUE1 which contains text before save and AUDITDETAILVALUE2 which contains text after save

AUDITDETAILVALUE1:

AUDITDETAILVALUE2:

As you can see this is not a same text. how it happened? This is because inial text had these unencoded entities. but richtext editor use only encoded html entities so editora automaticaly converted it. That's it.

2) Another situation with 'Applications' custom field.

It looks like RichText editor added end of line automaticaly before   Yes we will think how to compare richtext editor text without it.

3) Third is Date(date picker) fields issue. it looks this is Audit issue.

I will talk with QA to create bugs for second and third issues.

Thank you for sharing it with us!

-Alexander

Hi

DevOps bugs 728 and 729 have been created against points 2 & 3, it will be fixed in an upcoming DW release. Thanks.

BR, Oleg QA 

Hi Brian,

Based on Alexander's explanation of the data and your explanation that you're getting a different experience using Ecommerce vs PIM, I may have one answer:

• When using Ecommerce the UI will load all the data
• The controls try to populate it
• If some values don't match (i.e. list options no longer have "Blue"), the control either cannot select that option and stays empty OR could select the default
• When the user clicks "Save", even if they don't change that field, they are commiting the changed value to the database - which is then picked up by the Audit

As a side note and a rule of thumb, never do "Save" if you're not really saving anything - do "cancel" instead. This is a very common "human" behavior that should be avoided. If anything some "Modified dates" could be updated and lead to misinformation and false assumptions.

Hope that makes sense too.

Alexander, Oleg, and Nuno:

Thank you all for your responses and for opening the bugs on the two issues above.  Nuno, I am sure you are correct about your explanation of the behavior. In the ERP platforms that I have experience with, the user is not able to save a form where no changes have been made thereby avoiding the problem you describe.  My biggest concern is that the behavior that I have observed makes the Audit trail unusable for its purpose and does not meet the description in the documentation as I cannot determine who made a change and what changes they made:

Audit trails are typically used to raise accountability during internal investigations, and play a key role in good internal business controls. They provide proof of compliance and operational integrity, but also allow you to identify areas of non-compliance.

Our audit trails allow you to inspect:

• WHO changed something
• WHAT was changed
• WHEN it was changed

Hi Brian,

That sort of behavior (preventing the 'Save' OR even better, validating the last modified date prior to saving, in save someone else updated that same record while you were making your changes too) is a long time desire of mine too. Maybe for DW10 we can have it.

In the meanwhile, I guess we're stuck with this and it's a consequence of "bad data" and/or "bad user behavior" because:

• If the data was accurate - the UI would not have picked up different options, causing the change
• If the user did not hit "save & close" if he/she made no changes - because worst case scenario it could/would trigger a last modified date timestamp (depending on the object) which is misleading too

So I don't see the Audit as not working accurately, as much as I see the Products UI in Ecommerce when associated with bad data and/or bad user behavior; granted that the UI does not help prevent the situations.

Best Regards,

Nuno Aguiar

Hi

Bug #728 + #729 on Audit triggers has been fixed in Dynamicweb version 9.10.5

You can get this from the download section: https://doc.dynamicweb.com/downloads/releases

Kind Regards
Dynamicweb Support
Kristian Kirkholt