update timestamps of role/service/group on updating meta

[chandrasekhar1996]

Description

addresses https://github.com/AthenZ/athenz/issues/2526

Contribution Checklist:

• [x] The pull request does not introduce any breaking changes
• [x] I have read the contribution guidelines.
• [x] Create an issue and link to the pull request.

Attach Screenshots (Optional)

[havetisyan]

The modified field in the schema has CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) so any time the entry is updated, the field will be updated automatically. What is the use case when these are not updated?

[chandrasekhar1996]

The modified field in the schema has CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) so any time the entry is updated, the field will be updated automatically. What is the use case when these are not updated?

Taking the example of Role. To update tags for a role, putRoleMeta call is made in which the new meta has only the tags updated. Since the remaining meta fields are the same, the updateRole call doesn't actually update the row in DB and hence the timestamp doesn't get updated.

In the same method, processRoleTags does update the tags but only role_tags table is updated for that which still leaves the "role" tables modified field unchanged.

EDIT: also verified this behavior practically through the UI

[chandrasekhar1996]

another approach could be to check if something has actually been updated, similar to executePutRole. If nothing has been updated throw an error, else update the domain and role modified timestamp

[havetisyan]

so in this case we need to maintain the value returned from the updateRole calls. If it's false then it indicates that the role and any of the meta attributes were not modified. Then we also need to make sure to maintain the value returned from the processRoleTags if any of the tags were updated. So if the role was not updated but the tags were updated, we need to update the role last modified timestamp explicitely.

[abvaidya]

@chandrasekhar1996 is this PR still needed?

[havetisyan]

we do need to fix this but the calls are not quite in the right place. we should also have unit test cases for the tag updates to verify the last modification timestamp update. Maybe I'll just do the changes in a separate PR.

[havetisyan]

addressed by #2610