Adding 'Status types' to 'follow up' comments in knowledge articles

[Simon Ellis]

I've got a request from an end user asking if it was possible to add some additional status types to follow up comments in KA.  I don't see a way through the front end to be able to do it, so I imagine it would require a pdm load.  However I was wondering before dabbling whether it's okay to do so and add an additional 3 or 4 comments status types.  Are there any other areas I'd need to consider if doing this?  Am i likely to run into any issues doing this?

 

Thoughts would be appreciated....

 

Simon

[Kyle_R]

Hello Simon,

 

I had a browse through the issues that have come in, and no-one has asked that before, so you may be ahead of the field here. (Either that, or whoever has modifed this before found the process so trivial that they didn't bother to post about it. Take your pick. )

 

I'd say "Just try it." I can't see any reason why expanding that table by a few rows would present a problem (Apart from possibly at upgrade time if the default data there changes.) I don't see why it should be used by anything else.

 

Have a snuffle around, check out bop_sinfo for SREL . . .  but just go on a test system and try. Should be fine.

(Famous last words? I hope not!)

 

 

Having said that, there was this site which noted weird and wonderful side effects of working with this particular field, when they were working with a specific scenario of manually changing the Tenant of the Contact who worked on the Knowledge Document. The problems arose more from the unexpected manual change of the Tenant than the field.

But if your workflow involved anything like that, then testing around these areas would be recommended.

 

 

Thanks, Kyle_R.

[Simon Ellis]

Hi Kyle,

 

I gave it a go and found that although adding the values into the database table was easy enough and allowing visibility through the form was okay as soon as i selected one of the new values it would present an error message saying flag status is not allowed.  It would appear there are triggers set oob that don't allow use of other values, so what was hopefully going to be a quick easy amendment, I've gone back to my requester and said it's not possible.  It looks like it might be a bit of a huge effort just to add a few more values.

 

Cheers,

Simon

[Kyle_R]

Thanks Simon,

 

For completeness, I'll mention on this thread in case anyone else reads it that customisation via our CA team would still be possible. But as you said, probably not worth it here.

 

Flagging this thread as answered.

 

Kyle_R.

[Grant Bruneau]

Hi gizmo1969,

 

I played around with this today and figured out how to make it work.  It involves modifying kt.maj located in nx_root\bopcfg\magic.  The trigger below calls spel located in freeaccess.spl, which is encrypted.  I tried moving kt.maj to site\mods\magic but services failed to start, this file is likely called directly.  You might be able to place a mod file in site/mods/magic and override this trigger but I'm not sure how to do that.

 

Change the following line from

POST_VALIDATE O_COMMENTS_PostValidate_VerifyComment @ "@|kt_daemon|top|0" (id,FLG_STATUS,FLG_TYPE,DEADLINE_DATE,CLOSE_DESC) 60;//Verify if all comment fields values are permissible

to

POST_VALIDATE O_COMMENTS_PostValidate_VerifyComment @ "@|kt_daemon|top|0" (id,FLG_TYPE,DEADLINE_DATE,CLOSE_DESC) 60;//Verify if all comment fields values are permissible

 

I tested this a bit and didn't notice any undesirable behavior.  close_date is still updated when setting the status to closed and when changing it from closed to open.

[Grant Bruneau]

Well I spoke too soon, close_date isn't being updated when transitioning from the new status to Close.  I'll play around with this more next week.

[Simon Ellis]

That would be awesome... thank you....

[Grant Bruneau]

Didn't have much luck with this one.  When I removed FLG_STATUS from the following trigger the Close/Open dates are not set properly anymore.

POST_VALIDATE O_COMMENTS_PostValidate_VerifyComment @ "@|kt_daemon|top|0" (id,FLG_STATUS,FLG_TYPE,DEADLINE_DATE,CLOSE_DESC) 60;//Verify if all comment fields values are permissible

 

Next I tried adding a new post_validate trigger for the new status but that didn't work either.  Perhaps someone else could chime in?  It seems like this would be fairly simple if only we could take a look at the .spl file the trigger calls.