Modified dates in Site Contents should reflect content changes, not system changes
Looking at the modified values in Site Contents has always been a quick way to recognize where activity has occurred - if it has. Without running any code we can quickly see if a site has been used recently. (It was easier to eyeball this in SharePoint 2007 in the vertical listing than it is in SharePoint 2013+, but that's a different UI issue - tiles aren't helpful for every use case.)
For months now, a list no one has touched for over a year might say "Modified 23 hours ago". It seems as though lists and libraries are being "touched" by some background process, changing the modified time incorrectly.
An example would be the site in my Sympraxis Office 365 tenant at https://sympraxis.sharepoint.com/sites/Demos2013/_layouts/15/viewlsts.aspx
On that page, I see a number of lists and libraries that say "Modified 9 days ago" or "Modified 10 days ago". I know for a fact that I have not modified any of those lists or libraries in quite a long time (at least months) and I'm the only person who would be in there. I'm attaching a screenshot showing this.
I've seen this in multiple tenants on Office 365, so it isn't just something in my tenant. It's VERY confusing to end users and brings into question the integrity of the platform.
I've been told by support that this is "expected"behavior" and has been the case since SharePoint 2013. I believe this should be fixed. Please vote early and often!
sympmarc
shared this idea
AdminSharePoint UserVoice Admin
(SharePoint UserVoice Admin, Microsoft SharePoint)
responded
Thanks for this feedback. This is an example of how User Voice and Twitter brought this to our attention.
We have rolled out a fix to all of production for this issue. Going forward, Site Content’s dates will only update based upon real user behavior, not system changes.
It’s worth noting that this is a go-forward fix – we did not feel it right to go back and change existing dates.
Please let us know if you see any dates update that are unexpected.
38 comments
Comments are closed-
Richard SilverWings
commented
Bump!
-
Richard SilverWings
commented
I guess this is relevant to the cause... goo.gl/b3X7G2
-
R D Johnson
commented
This should definitely be fixed in some way. We have policy that specifies that abandoned sites will be archived and permissions revoked. It is not easy now to quickly ID dormant sites. I do not understand the response Microsoft gave. A search crawl does not modify the content it finds. When I read a book, the book is not changed, except maybe at the quantum level.
-
Richard SilverWings
commented
Bump!
-
Gaya
commented
If I could cast all my 10 votes on this topic, I would do that. Everyday!
-
SDADM
commented
Any update?
-
Richard SilverWings
commented
How many votes are needed in order to have this issue addressed?
-
Stefanie Sloper
commented
It used to work properly in 2007/2010, so why was it changed and why is it difficult to revert?
-
Shawn Miller
commented
Thank you for your initial investigation and explanation.
I agree with the others that this would definitely be worth implementing.
-
Matt Wade commented
In response to 7/15/16 admin comment, definitely still worth it, guys. #justdoit
-
Marc Wenning commented
this is very confusing to end users and admins alike, when we go into a library or site that we know hasnt been updated in some time but the last updated date does not reflect that. This change really does need to be implemented so we can see a true last updated date buy end users not services or features.
-
Lorne
commented
I would certainly like to see this change as quickly as possible! On-prem and online versions.
-
Anonymous
commented
Thanks for bringing this up, Marc! Was seeing the same thing in an SP 2013 instance at my old job and thought like you did, it must be some service updating things, but why, and for what purpose? Search indexing would be the first thing to come to mind, but this shouldn't modify anything. If it is, MS has some 'splaining to do!
-
speedydaniel84
commented
We have the same problem.
Trying to setup a site lifecycle for teamsites is very difficult.
At the moment our operating / monitoring department tries to generate a report via Varonis to filter out the system users accesses. Hopefully this 3rd party tool can give us a workaround until MS is fixing it. -
Brian Kinsella
commented
same behavior here across all tenants I work (worked) with: mine and customers. Thank you Marc for flagging - been nagging me for a while!
-
Paul Stork
commented
This is even worse if you figure that this date is often used for retention policy rules. For example a rule that deletes or archives a file when it hasn't been modified in 90 days. If touches by the system update the modified date then it invalidates the whole premise of basing retention policies off these dates.
-
Irina Winsley
commented
I also noticed this issue in our Office 365 tenant. It gives me a lot of grief with our collaboration workspaces. To keep our workspaces tidy, we have a policy of closing spaces that have not been used for over 3 months. By checking the modified dates in Site Contents I could easily establish in SharePoint 2010 whether a particular space has been used in the last 3 months or not. In Office 365 however date modified in Site Contents always indicates that all workspaces have been modified in the last week or so, even if no one was accessing or using their content for a year. Modified dates in Site Contents should reflect content changes. I strongly believe this should be fixed.
-
sympmarc
commented
I've also submitted this to office365.uservoice.com at https://office365.uservoice.com/forums/264636-general/suggestions/15112038-modified-dates-in-site-contents-should-reflect-con If you care about this, please vote there as well.
