Text in Layouts

sunsetsystems wrote on Tuesday, June 22, 2010:

A client wants to sprinkle some long-ish passages of descriptive text in with his layouts.  This is not data to store for each instance of the form, but rather part of the form, much like a label.  So I guess I’ll make a new field type “Static Text”, and have the layout editor give it some special treatment (like not creating a database field for it, and allocating extra space in the layout editor GUI for entry of the text).

Any thoughts/comments?

Rod
www.sunsetsystems.com

tmccormi wrote on Tuesday, June 22, 2010:

That would be useful.  Could you make it optionally display static on the screen or just be visible as mouse-over “help” ?
-Tony

sunsetsystems wrote on Tuesday, June 22, 2010:

The request is to display it statically on the screen.  The “Description” field of a layout item will already display as a tooltip during data entry, however that is limited to 255 characters.

Rod
www.sunsetsystems.com

sunsetsystems wrote on Tuesday, July 27, 2010:

I went ahead and added logic for this.  Affected modules are library/options.inc.php and interface/super/edit_layout.php.

bradymiller wrote on Wednesday, July 28, 2010:

Rod,

Why removing the default field?

Also, use the new security approach in scripts that have already been converted (options.inc.php and add_transaction.php); see here for more information:
http://www.openmedsoftware.org/wiki/Active_Projects#PLAN

Here’s a link to my commit so you can see my changes (only a couple changes, but important):
http://github.com/openemr/openemr/commit/de23d0f60367aba54dace93cef158a9714e7b76b

In options.inc.php, placed the htmlspecialchars around your description. It’s vital to be liberal with this function and surround any code that the user can potentially modify before it is outputted to the screen; this effectively eliminates cross-scripting attacks, and it’s pretty much a good idea to get in the habit of doing this for all code.

In transaction_add.php, note that file has been converted to utilization of binding in sql statements, which eliminates sql-injection (and no longer need to manually escape variables via the formdata.inc.php related commands ). The one command I changed is the unusual scenario, since binding can not be used on column names. So, in this case need to manually escape the column name variables (could potentially have a a quote - never know) with the add_escape_custom() function. This binding method can only be used in scripts that have been fully converted, such as the add_transaction.php script (check out the above wiki link describing this security project, and you’ll see converted files have the obvious sanitize_all_escapes=true; flag at the top).

Hope this makes sense. Let me know if you have any questions.

-brady

sunsetsystems wrote on Wednesday, July 28, 2010:

Hi Brady,

Default was removed because nothing seemed to be using it.  Did I miss a case?

For the description we actually wanted the flexibility to include some types of HTML markup like font size, colors, bolding, even images.  So htmlspecialchars() is not the answer for this one.  Any suggestions?

Thanks for the point about escaping column names.  I’m pretty sure I preserved your use of binding in add_transaction.php.

Rod
www.sunsetsystems.com

bradymiller wrote on Wednesday, July 28, 2010:

hey,

Regarding default value, agree nothing seems to be using it.

Didn’t realize you’d be including HTML markup (assumed not since you wrapped it in the nl2br function). I’ll change it back. In the future when all output is enclosed by htmlspecialchars in openemr (guessing will take at least a year), could then come back and perhaps figure out a way to make this item more secure.

And, yes, you did preserve the binding.

thanks,
-brady