Notifications

4946 views

Description

The valid_to date on knowledge article (kb_knowledge) indicates the date up to which that article is valid. Articles will not be searchable beyond the valid_to date.

The following changes are introduced in London Patch 10 (LP10), Madrid Patch 7 (MP7), New York Patch 1 Hot Fix 1,  New York Patch 2 (NP2) onwards,

For Existing Articles:

  • A fix script to change valid_to of existing articles from 01/01/2020 to 01/01/2100.
  • This fix script will update only those articles which have valid_to="01/01/2020".
  • This fix script will run only the first time customer upgrades to any of the above mentioned or later patches.

For New Articles:

  • The default value of the knowledge article valid_to field is changed to 01/01/2100 if and only if the default value has not been customized to a date other than what is shipped by ServiceNow in the base product.
  • Any new article created after upgrading to the above-mentioned patches or later will default valid_to to 01/01/2100.

From New York onwards,

  • Users can configure the default number of days an article is valid from the date of creation at each knowledge base level.
  • For newly created articles, valid_to value is defaulted based on the validity configured at the knowledge base level.
  • If validity is not configured at the knowledge base level then
    • valid_to value of the newly created article defaults to 01/01/2100.
    • valid_to value of the new version of the article defaults to 01/01/2100 while checking out an existing article (when article versioning is enabled)

Please Note:

1) If you have any customization around valid to date this change will not override the customization:

  • Fix will not update any article where the author has explicitly set the valid_to date on the article to be something other than 01/01/2020.
  • Fix will not update the default value of the valid_to field if it has been customized to something other than the default shipped in Base Code.

2) Since the valid_to date defaults to a future date that is more than 20 years beyond the current date, you may run into unexpected behavior if a date format that uses YY year format (eg. dd-MMM-yy, dd-MM-yy) is set as the system date format (glide.sys.date_format system property) or user preference (via My Profile -> Date format). For instance, 01/01/2100 gets saved as 01/01/2000.

Please set the date format (glide.sys.date_format system property/ user preference) to a valid option that uses YYYY year format (eg. MM-dd-yyyy, yyyy-MM-dd).   

 

Steps to Reproduce

  1. Navigate to Knowledge > Articles > Create New
  2. Populate the required fields and save the article.
  3. Verify the valid_to date value

Workaround

Please see the fixed targets for the fix. If you are on the fixed targets for this PRB you will see default date for Valid To is changed to 01/01/2100

For more information about Article Validity please refer to the NY doc:

https://docs.servicenow.com/bundle/newyork-servicenow-platform/page/product/knowledge-management/task/create-a-knowledgebase.html

Additional Info:

Also, see this KB article KB0782953 if Valid_to date is set improperly when the date format for the system is changed to - dd-MMM-yy

 

Related Problem: PRB1353174

Seen In

Fuji
Geneva
Helsinki
Istanbul
Jakarta
Kingston
London
SR - IntegrationHub - Docker Integration v1.0.2
SR - IntegrationHub - Infoblox Integration v1.0.1
SR - IntegrationHub - JIRA Service Desk Integration r2 - v2.0.7
SR - IRM - Audit Management - New York 2019 Q3
SR - IRM - GRC Profiles - Madrid 2019 Q2
SR - IRM - GRC Workbench - New York 2019 Q3
SR - IRM - PA Premium Integration - New York 2019 Q3
SR - IRM - Policy and Compliance - Madrid 2019 Q2
SR - IRM - Risk Management - New York 2019 Q3
SR - IRM - SIG Assessment Legacy - Madrid 2019 Q1
SR - IRM - Vendor Risk Management - Madrid 2019 Q1
SR - ITOM - CMDB CI Class Models - 201908
SR - ITOM - Discovery and Service Mapping - 201908
SR - ITOM - Discovery and Service Mapping - v1.0.35
SR - Security - Integration Framework - Madrid 2019 Q2
SR - Security - Support Common - Madrid 2019 Q2
SR - Security - Support Orchestration - Madrid 2019 Q2
SR - SIR - Security Incident Response - Madrid 2019 Q2
SR - SIR - Security Incident Response PA Content - New York 2019 Q3
SR - SIR - Store SecOps Setup Assistant - Madrid 2019 Q2
SR - SIR - Store Threat Core - Madrid 2019 Q2
SR - SIR - Store Trusted Security Circles Client - New York 2019 Q3
SR - VR - Qualys - New York 2019 Q3
SR - VR - Vulnerability Response - New York 2019 Q3
SR - VR - Vulnerability Response PA Content - Madrid 2019 Q2

Fixed In

London Patch 10
Madrid Patch 7
New York Patch 1 Hot Fix 1
New York Patch 2
Orlando

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-04-07 10:12:47
Published:2019-10-31