BTW, isn't the modified date field used in the Security Center, for the "Old Passwords" section? Assuming it is, wouldn't that make that view basically useless?
But I'll wait for your response first, before any further conjecturing. Thanks.
I'm not sure, but I think you might be the same Robert I just responded to regarding the discrepancy you are seeing in the Security Center between your PC and Android devices. I asked about the numbers at the top of the Security Center because I think the issue might have something to do with an issue we have in the Android app where it's showing the wrong modified date in the details view, and that could be throwing all sorts of things off.
Yes, I am the same person.
The issue I am discussing (in this topic) though, is not pertaining to any particular platform, but around the expectations of the "modified date" field itself.
1. I'm asking about the v5 behavior of the "modified date" field and what I think is a new behavior in v6.
2. I brought up a question around how "modified date" plays a role in the new Security Center, when computing the age of a password.
Right now, we have a known bug with the modified date in Android. It's showing the incorrect date when certain actions are taken on records when it shouldn't. The functionality is working correctly, meaning records are sorting correctly in the Recents filter, and syncing working correctly, but the data is getting updated when it shouldn't. That will be fixed in the next release.
Unfortunately, it turns out this has nothing to do with what you are seeing in the Security Center, which is what I thought I had figured out. I'll get back to you about that issue in the other thread.
The date for handling old passwords is different than the modified date for a record, so when you see the modified date change, that doesn't mean mSecure sees that the password was changed. There is a specific date field in the database that is used to check when the password field data was last changed.
Thank you for taking the time to reply. I understand there's an Android bug. I understand there's a different password date field for Security Center.
I am asking about what I think is different behavior/interpretation of the Modified Date field in v6 vs how it was back in v5. Can you please reply about the following, the question is hightlighted:
You said in v6 that simply viewing the password is now expected to bump/touch the modified date field. This behavior is seen today in Windows v6.
Is this new behavior/interpretation in v6? Modified date now to be updated when a password is viewed. This was not the case back in v5, I'm almost 100% sure of that.
This topic is not about the Android bug. I also now understand Security Center uses a (hidden) password date.
This is asking about what I think is new v6 behavior regarding the "Modified Date" field. It sounds like new in v6 is that when a password is simply viewed, the new v6 behavior is to update the "Modified Date" field. Can you please verify that my understanding is correct? I'm pretty sure this is different than how "Modified Date" was touched in v5.
Your bold text in your last paragraph is, in fact, related to the Android bug. You are seeing the modified date get updated when it shouldn't be, and that is because Android is updating the modified date incorrectly. Does that make sense? You should not see the modified date get updated when you view a password. The modified date should only be changed when you actually modify data in the record.
When the next release is out, you will no longer see that happen.
While testing the beta version (6.0.257.0) of mSecure on my PC, I'm noticing that if I view a record I can see the date created and date modified fields. If I click on the pencil to edit the record, but actually do not change anything in the record - and then click on the "X" to get out of the record, the date modified is not changed - However, If I click on the check mark instead, - even though I did not change anything within the record, the date modified changes to today's date.
@Noella Thank you for bringing this to my attention. It definitely shouldn't update the modified date if no data is changed. I will write that up for the developer to fix, though I'm not sure it will get in this upcoming release we hope to publish today.
In a thread that I posted about what I thought was a problem with copying to clipboard was causing the modified date to be bumped. The response was that viewing the record is now expected to bump/touch the modified date field.
Is this new behavior/interpretation in v6? Modified date now to be updated when a record is viewed?
I've used the modified date as an indicator or reminder of the last time I actually modified (clicked edit) the record. I'm pretty sure that's how it was in v5.
Assuming it's now just a way to narrow a search to "recent' records, then I would hope the implementation would consider tracking a "viewed date" and leave the "modified date" as truly what "modified" means.
Further, if the modified date now gets updated a lot more frequently just due to "viewings", that date field becomes almost useless to me.