Hi Divya,
I ran a search for the string "untitled document" against an ITSM 14.1 installation using Notepad++ and found it in these file locations.
C:\Program Files (x86)\CA\Service Desk Manager\bin\perllib\5.12.2\CGI.pm (1 hit)
Line 1720: $title = $self->_maybe_escapeHTML($title || 'Untitled Document');
C:\Program Files (x86)\CA\Service Desk Manager\bopcfg\www\wwwroot\scripts\msg_cat.js (1 hit)
Line 2153: __messages["untitled_document"]="untitled document";
C:\Program Files (x86)\CA\Service Desk Manager\sdk\scripts\detail_KD.js (1 hit)
Line 1015: doc["SET.TITLE"].value = msgtext("untitled_document");//"untitled document";
C:\Program Files (x86)\CA\Service Desk Manager\sdk\scripts\msg_cat.js (1 hit)
Line 2194: __messages["untitled_document"]="untitled document";
NB This search was not done within executables, just against the plain text files.
Eyeballing it, the most likely is msg_cat.js, because the CGI.pm file uses sentence case for its string, and the other two locations are in the Software Development Kit.
I also ran a search against the database (I used pdm_extract -ALL > ALL.txt against a small sample database) and only found it in the SKELETONS table. It existed only because it had been created against knowledge documents without titles, as per the process you described. So it is less likely to be an item coming from the database.
Testing msg_cat.js, I found it was possible to replace the string "untitled document" with a different string, and then it would replace the Knowledge Document Title with that string instead.
Then I tested replacing with a blank value, and this gave the result of not populating anything into the Knowledge Document Title, as requested:
__messages["untitled_document"]="";
I did a recycle at this point to pick this up. Not sure why it was not picked straight up, when the first text change to another value worked straight away. (I'm guessing it was stored in the server SDM browser cache.)
So having a blank Knowledge Document Title can be done.
CAUTION - POTENTIAL UNSUPPORTED CUSTOMISATION
But note that I am still not sure if this is a GOOD IDEA. You'll need to do your own testing to make sure of this. In particular, make sure that you test out the "rework" scenarios to make sure they aren't messed up. I didn't test the "mandatory" option for this field either. That's also over to you - but I'm hoping it will get further now.
In particular, read this reference Files That Should Not be Modified which includes msg_cat.js.
(I took a shortcut in my testing above by using the live files - you'll need to work through the /site directory.)
"Although you cannot modify these files directly, you can add additional information to them. Each restricted file ***.htmpl (except for menu_frames.htmpl and reports.htmpl) has a corresponding ***_site.htmpl file that you can modify. For example, you can add additional information to ahdtop.htmpl by modifying ahdtop_site.htmpl, or add new messages by modifying msg_cat_site.js.
The ***_site.htmpl file corresponding to each restricted file is loaded after the main file so you can override or change JavaScript in the main file. Use caution when adding information, as badly designed changes to these files can cause unexpected problems throughout the CA SDM web interface."
Thanks, Kyle_R.