[Human Readable Change History] [Human Readable Change History] Change in Attribute Id linked to encrypted table

Forge Component
(23)
Published on 27 Jul by Justin James
23 votes
Published on 27 Jul by Justin James

Hello Human Readable Change History Devs,


The Human Readable Change History is working well for almost all changes that we track in our application, so thanks for that :). However, we do run into a problem in the case where an attribute Id of table 1, which is linked to table 2 in which some columns are encrypted, is changed. In that case instead of showing the change in attribute Id, it will show an encrypted value. 

I haven't been able to figure out how to prevent this and only show the change in Id. Does any of you know how to solve this?

Thanks in advance!

Hi Khadija,

You can utilize the AttributesToIgnore parameter to ignore the encrypted parameter.

Regards,

Daniel

Hi Daniël,

Thank you for the reply. The thing is, I would like to know the changes in the attribute identifier of table 1, which on itself is not encrypted. But what is shown as a change instead of the identifier, is a linked (encrypted) values of table 2. Is it possible to show only the changes in the identifier?


Best wishes,


Khadija


Hi Khadija,

I think I did understand, but thought (not tested) was that if you ignore the encrypted value than that is not shown. But I see then still you don't see the changed Identifier. I would have to dive into it, and not have time for that. I would suggest to dive into the component code and figure out how it works. Maybe you need to clone it and make a custom version.

Regards,

Daniel

Hi khadijam,

It would be helpful to understand what method has been used to ensure the entity attribute data has been encrypted.  Would you mind explaining this, if possible?

Also, I am assuming you have specifically switched on encryption in some way.  However, if not, what has lead you to the conclusion that it is encrypted?

This plugin queries from the database, and puts the result in a text attribute so if the database server is not managing the encryption, that could be the problem.

Kind regards,

Stuart

Stuart Harris wrote:

Hi khadijam,

It would be helpful to understand what method has been used to ensure the entity attribute data has been encrypted.  Would you mind explaining this, if possible?

Also, I am assuming you have specifically switched on encryption in some way.  However, if not, what has lead you to the conclusion that it is encrypted?

This plugin queries from the database, and puts the result in a text attribute so if the database server is not managing the encryption, that could be the problem.

Kind regards,

Stuart

Hi Stuart,

For encryption of some columns in table 2 we've used the SQL function EncryptByPassphrase on some of the columns, although not on the Identifier. The reason I think that the result is encrypted, is because if i the change relates to an Identifier with a table that does not have any encrypted columns, the result is shown normally. For example, if an attribute with an User Identifier is changed, the change is described by the UserName. In case of the attribute linked to table 2, it will describe it with "unreadable" signs. Do you know if there is a way to not show the text attribute of the linked table, but only the Identifier itself that changed in this specific case?

Kind regards,


Khadija


 

Daniël Kuhlmann wrote:

Hi Khadija,

I think I did understand, but thought (not tested) was that if you ignore the encrypted value than that is not shown. But I see then still you don't see the changed Identifier. I would have to dive into it, and not have time for that. I would suggest to dive into the component code and figure out how it works. Maybe you need to clone it and make a custom version.

Regards,

Daniel

 

 Hi Daniël,

Oke, I hope someone perhaps has some ideas already because they use this component, but if not it would make sense to look into a custom version.

Kind regards,

Khadija

Solution

Hi Khadijam,

Thank you for explaining the encryption.  But re-reading your post, I see that is not the main issue.  

It sounds like you are primarily looking for just the changes to the attributes on Table 1, regardless if they are identifiers or text, etc.

The plugin works hard to find human readable text to display for an attribute instead of just displaying ids. As an example when an Id=5 references a static entity with label "Completed", instead of displaying 5, the plugin wit display "Completed".

The plugin has a list of attribute names to try first, and if they do not match, it will find the first text attribute.

You could prevent the system looking for the first text attribute by adding Id to one of the site properties either "IdentificationEntityAttributes_First","IdentificationEntityAttributes_Second", "IdentificationEntityAttributes_Third".

If you added it at the end of "IdentificationEntityAttributes_Third" it would look like this "codigo,code,Codigo,Code,CODIGO,CODE,Id".

However, it may be simpler to create a separate component to just JSON serialize the previous and new record then compare them.  This would be less "human-readable".

I hope this helps!

Kind regards,

Stuart

Solution

Stuart Harris wrote:

Hi Khadijam,

Thank you for explaining the encryption.  But re-reading your post, I see that is not the main issue.  

It sounds like you are primarily looking for just the changes to the attributes on Table 1, regardless if they are identifiers or text, etc.

The plugin works hard to find human readable text to display for an attribute instead of just displaying ids. As an example when an Id=5 references a static entity with label "Completed", instead of displaying 5, the plugin wit display "Completed".

The plugin has a list of attribute names to try first, and if they do not match, it will find the first text attribute.

You could prevent the system looking for the first text attribute by adding Id to one of the site properties either "IdentificationEntityAttributes_First","IdentificationEntityAttributes_Second", "IdentificationEntityAttributes_Third".

If you added it at the end of "IdentificationEntityAttributes_Third" it would look like this "codigo,code,Codigo,Code,CODIGO,CODE,Id".

However, it may be simpler to create a separate component to just JSON serialize the previous and new record then compare them.  This would be less "human-readable".

I hope this helps!

Kind regards,

Stuart

 Hi Stuart,


Thank you for your very clear explanation, I was not aware it would pick the first text attribute after those site properties. I will check which solution that you suggested will fit our needs best and let you know if it worked (and mark as solved of course if it does).


Best wishes,


Khadija