Default valid_to needs to remain as original, when checkout article

[LeanNow]

When a KM or Author a KB article checkout an article to update, the valid to date changes and gets extended by one year.
I know this happen because of KBCommon
But is required the other functionalities still/remains.

For example such as 2100 and default as KBase Validity (FOR FIRST TIME).
I mean:
The valid to date must remain the same as before/Preserve the same date when manager or author checkout for some updates.

How can we complete the script include to add his exception without disable all others features?

If I disable KBCommon ScriptInclude in the default dictionary value for valid_to field we lose the others features.

Thanks


KBCommon Script

[LeanNow]

Hi Bert
Thanks is a really good idea.

I Think I will set with order 1100 because there is other one with 1000

Something Important if they want to update in the future the valid to, don't have option to change that field with this B rule. So do you think... is possible, offer an exception to have in future if they want to change in the future valid to intentionally?
How can we left that "window" open if that would be necessary in the future?

I was checking filter conditions.. don't want that change automatically... when checkout is clicked... but with a simple update and save is needed to left available the option to change valid to.
Any idea?

many Thanks

[Bert_c1]

Hi LeanPach,

You can include a check in the BR as follows:

var gdt = new GlideDateTime();
gdt.addYears(1);
gs.info("new DateTime: " + gdt);

var kbrec = new GlideRecord('kb_knowledge');
kbrec.query();
while (kbrec.next()) {
	if (kbrec.valid_to > gdt) {
		gs.info("KB: " + kbrec.number + " has valid_to greater than 1 year: " + kbrec.valid_to);
	}
}

I tried that in Scripts background, BR logic would be:

var gdt = new GlideDateTime();
gdt.addYears(1);
gs.info("new DateTime: " + gdt);

if (current.valid_to > gdt) {
	gs.info("KB: " + kbrec.number + " has valid_to greater than 1 year: " + kbrec.valid_to);
	current.valid_to = previous.valid_to;
}

change the value in line two to the number of years you are happy with. And comment out the gs.info() lines after testing.

Also see:  PrecBetweenAssignmentAndBusRules

for some related information.

[rayancsdc324515]

If you're looking for a way to achieve the exception without modifying the code of the KBCommon ScriptInclude, and you don't want to disable the entire KBCommon functionality, you might need to explore if your system or software provides any built-in configuration options or settings for this.

Here's a general non-coding approach you could consider:

1. Contact Support or Documentation: Check the official documentation of the software or system you're using. There might be specific settings or configurations mentioned that can help you achieve the desired behavior without coding.

2. Configuration Options: Explore the configuration settings of your software. Look for any options related to the validity date of knowledge base articles, article checkouts, or updates. There might be an option to disable the automatic validity date extension or to set a custom behavior for specific cases.

3. User Roles and Permissions: Sometimes, software allows different user roles with varying levels of permissions. Check if there's a way to define different behaviors based on user roles. For example, authors might have one behavior while managers have another.

4. Workflow Customization: Some systems allow you to define custom workflows for article creation and updates. If your system has this feature, you might be able to define a special workflow for the initial creation of articles that sets the validity date differently.

5. Extensions or Plugins: If your software supports extensions or plugins, there might be one that adds the functionality you're looking for without modifying the existing KBCommon script.

6. Consult Vendor or Community: If you're unable to find a solution within your software's settings or documentation, consider reaching out to the software vendor's support team or searching for community forums where other users might have faced a similar issue.

7. Workaround: As a temporary measure, you could manually adjust the validity date after the checkout process for the cases where you want to preserve the same date. While this isn't an automated solution, it could serve as a workaround until you find a more suitable approach.

Keep in mind that the feasibility of these options depends on the capabilities of your software or system. If your software is highly configurable, there's a good chance you'll find a way to achieve the exception you need without writing custom code. rekey service

[LeanNow]

Excuse me, I think I didn't express myself quite well. Thank you. I don't want to change the valid to with Business rule I have already another BR for that.

I like the previous BR you suggest to me for maintain previous valid to as it was.

NOTE:

I have a concern. with that BR you can't change the "valid to" fied intentionally and save new value.
Because the BR take that as an update and maintain previous value as a current value.

That is correct but we need that behavior when they click on checkout for update and publish again.

For restrict KBCommon behavior.
BUT the most concern I have, what happen if we intentionally wants to change or extend valid to.
We need to left an option to do that.
So we can add something to this BR?:

(function executeRule(current, previous /*null when async*/) {

    current.valid_to = previous.valid_to;

})(current, previous);

for conditioning this making an exception
if the user check out maintains previous value, OK
but if the user wants to update "valid to " manually and save intentionally that should be allowed...

How can we achieve that?

I'm checking if we can work with the condition of the BR
I want to achieve this: 
Have this business rule and maintain previous "valid to" date when checkout unless the user change manually the field and save the form and then after that update and save, then publish again or check out again if its necessary.

Allow manually change of that field.
Thanks a lot

[Bert_c1]

Hi LeanPach,

Is there some future value that you don't want to allow, however it is set? If so, the BR can do that. To allow any value in 'valid_to' when a user updates that you can include a check to "gs.getSession().isInteractive()" being false.

if (gs.getSession().isInteractive())
	return;

var gdt = new GlideDateTime();
gdt.addYears(1);
gs.info("new DateTime: " + gdt);

if (current.valid_to > gdt) {
	gs.info("KB: " + kbrec.number + " has valid_to greater than 1 year: " + kbrec.valid_to);
	current.valid_to = previous.valid_to;
}

Test that for the BR logic.