Brief development roadmap

OpenEMR Development
1

bradymiller wrote on Thursday, September 17, 2009:

hey,

Just to get input, figured I’d post a brief proposal for a roadmap concerning future 3.2 release and the current 3.1 release.

## Future 3.2 release ##
** Change the calendar default to Jason’s outlook (we will change the name to avoid microsoft conflicts) as soon as possible to get as much testing time as possible with this calendar. Sorry in advance to Tony’ tech writer because this will require several screenshot changes for the future manual.

** Optimize the LBF (layout based forms) for internationalization. (will require just a bit of code to allow turning off/on translation of this element)

** Also hopefully Jason’s visual form maker will be done by then; I’ve seen a prototype and it’s very cool.

** To by consistent with previous versions, I also want to make the admin see calendar by default (have them authorized by default), which is a simple fix in setup.php

** And of course, a lot of CCHIT stuff.

## Current 3.1 release ##
** Continue to support with bug fixes and patches. Plan to offer patches in the form of zipped files that contain all the revised full files in the directory structure of openemr. This makes it very easy to use patch in windows via extract to openemr directory and I’m guessing a similar method can be used on the file in linux.

** known big bugs to work on are apostrophes and sessions (and of course will commit these to above development branch also)

-brady

2

bradymiller wrote on Friday, September 18, 2009:

Also, another large undertaking that I just thought to consider for the 3.2 development cycle is migration of all configuration setting from the source to the mysql database. This would include the following:

** auto-detection of the web_root and webserver_root directories (it seems all other php projects do this, so shouldn’t be hard) in the interface/globals.php file, so it doesn’t need to be hard-codes

** Migration of all configuration setting from interface/globals.php and includes/config.php to mysql database. This actually isn’t that difficult, just need to fill up all the settings in these files with a sql query instead of the current hard-coding; could also create mechanism for user specific settings. The more difficult task will be creating the administration page to configure the settings.

** Migration of other setting in custom/statement.inc.php, custom/clickoptions.txt, custom/code_types.inc.php, and library/lists.inc files into mysql database. custom/clickoptions.txt can likely get worked into the admin->lists stuff but the others would need to be likely worked into above not yet created configuration admin screen.

-brady