Need advice: Is it a good idea to include an HTML field in an incident record?

[HugoFirst]

I have a set of users who are asking for an HTML field in the incident record.

The business case is so they can include images in the description of the incident.

To analyze this enhancement in our dev instance, I created a new field of type HTML on the incident table named "u_description_html" with a label of "Description (HTML)".   I added that to the incident form where I opened an incident and inserted an image in the Description HTML field.

When I saved the record I found that the html description looks like I would expect, but I noticed 2 negatives.

1. Images cannot be copy/pasted into the Description HTML field.   They must be uploaded and then inserted.   To be fair, the insert tool manages both actions in one operation, but it is user apparent.

2. The uploaded images are stored in the same table as the UI images.   That's right, when you look at "System UI" -> Images, you see not only the   images in the ServiceNow UI, but also the images uploaded for the incidents.

Here's where I project out into the future:

In the last year we opened over 24,000 incidents. If only half of these contain images and we average 1.5 images per incident, that would expand the number of images in the db_image table to about 18,000 images.   It currently contains 134 images ( and that includes the images for knowledge articles ).

Also, if we proceed with this, I'll have to write a script to copy the description field to the new description_html field for all our incidents, about 49,000 incidents.

Any idea on how long that will take to run?

Finally, to reiterate my question, Is this a good idea?   Are there any better alternatives?   Are there any regrets that I will have if we proceed with this?

[HugoFirst]

I'm adding a couple of more observations, based upon the fact that the image is stored in the same table as all other images and that the image is saved USING THE SAME NAME AS IT HAD WHEN I UPLOADED IT.  

So the question pops into my mind, what if someone uploaded more than one file with the same name, say image01.gif?   I experimented and here's what I found.

For the experiment, I put 3 different images ( all .gif ) into three folders and gave them the same name.

1. I opened an incident record and uploaded image-1 to the Description (HTML) field. It worked as I would have expected.

2) I then opened a second incident and uploaded image-2 ( but with the same name as image-1 ) and here's where it gets SPOOKY!   In the upload tool, I previewed image-1, even though I just uploaded image-2.   In this second incident,   the image displayed was image-1, not image-2.   I viewed the db_image table ( System UI -> Images ) and I saw image-2.   image-1 was NOT IN THE TABLE.

3) So I opened a third incident record and uploaded image-3 ( still with the same filename as image-1) to the Description (HTML) field.   Again, image-1 showed as the preview in the upload tool.   Again, image-1 displayed in the Description (HTML) field, even though I had just uploaded image-3. I viewed the db_image table ( System UI -> Images ) and I saw only image-3.   image-1 and image-2 were nowhere to be seen.

So I conclude the following:

1. The first image uploaded to a given name is preserved somewhere ( as a .gifx file ) and served up whenever the image is fetched.

2. Any subsequent image uploaded will replace the original image in the db_image table.   But it will NOT be served up when the image is fetched for an incident.

[HugoFirst]

I haven't heard anything back on this question, so I assuming that I'm either on the leading edge in terms of providing this feature, or that I'm stressing over nothing and shouldn't be concerned about the implications of adding an HTML field to the incident form.

On the chance that it is the former, I will provide an update of what I'm doing.

1. The upload widget has 2 options, "Image Library" and "Attachment".   The "Attachment" options works fine for our purposed.

2. In order to require the users to attach the images, I restricted access to the db_image table. See the discussion at this link for details: How can I restrict a user's ability to insert images into the db_images table?

3. The option to select the image library still remains, but the "new" button that allows the user to upload an image is gone.

4. To save the user a click ( to switch from "Image Library" to "Attachement", I'm looking to remove the option for "Image Library" from the widget.   While I don't know how to do this, I'm pursuing it under another post.

Link: How can I remove the "Image Library" option from the widget used to upload lmages to HTML fields?

[HugoFirst]

The image upload widget now works as best as I can get it.   The default type is "attachment" and the user is required to attached the uploaded images to the incident record.   I submitted this implementation to my interested users for evaluation and I'm getting good results back.   While they would prefer copy/paste functionality, they see the "upload and copy" model as definitely useable.   We plan to include this feature in our next release.