We are developing new functionality to display national holidays. The module will alert/prevent if user wants to create a visit in national holiday.
To display such events in calendar we need to create two pre-defined categories.
Due to dynamic numbering of categories and the fact that any OpenEMR install can insert his own categories , we don’t see it possible to simply insert category 12 (or any other).
Can we reserve categories 6 and 7 for that purpose?
Another way is to store category ID in globals, but we can’t use this approach for existing installations.
Looking at the code under interface/main/calendar/modules/PostCalendar/pntemplates/default/views/ it looks like the hard-coded category IDs are 1, 2, 3, 4, 8 and 11. So offhand it seems OK to use 6 and 7.
That code BTW is quite an adventure. Eventually someone will surely want to replace the calendar with something else.
Granted it may be overkill just for this but this is a perfect candidate for class structres that accept appointment record and let users work with mnemonics. The national holiday schemes can be complex.
@Brady I can but then it will not be compatible with calendar logic of processing “special” events, that relates to hardcoded category ID.
What I suggest: reserve first 100 category IDs for OpenEMR internal purposes. After installation, insert demo category with ID=100. This way any new categories set by users will not interfere with our internal categories. For existing installation we can issue an update to move category IDs > 11 to 100’s area in both events and categories tables.
But can’t that basically be considered hard-coded if have the pc_holiday column toggled to 1. For example, if set a global that sets the “hard-coded” id from this, won’t that suffice?
Hi Brady,
I’d like to hear more about this. I think adding an extra column will require more effort, more custom modification to postcalendar core where it was not yet modified, and will not bring larger benefits.
Re: my suggestion to start user-defined categories from 100: MU2 COQ commit uses hardcoded categories 12-14 and does not take into account the fact that there may be user-created categories.
The core issue here is upgrading. Upgraders whom are using 6 and 7 will essentially break and trying to migrate id’s like this will open up a can of worms that could lead to incorrect mapping of data.
Note the MU2 CQM added 2 new columns to that table to support an ‘Active’ setting and a ‘Sequence’ setting(also was added to the GUI end in Administration->Other->Calendar). If a category is going to be “special”, then doesn’t it make sense to store this information in the database item itself rather than hard-coding it in the codebase?
My point above is that whether it is hard-coded or mapped in the database is arbitrary. The code that is written to support it should be interchangeable(and if it’s called multiple times, could be optimized by placing it in a global):
if ( $category_id == 6 ) then do something
if ( is_holiday_category($category_id) ) then do something
Hi Oleg,
Can you give me a bit more information on what the 2 categories you plan to create? Are they both going to be the same type of holiday?(just unclear why using 2 caegories nad not just 1) If you already have code, would make sense to post it now so can get a sense of the most ideal way to do this. Storing in globals may not even be necessary. If do end up storing it in globals to optimize things, note it wouldn’t be stored in the globals sql table, but the globals would be created when set up the globals in interface/globals.php .
-brady OpenEMR
I noticed code on your repo regarding this. Look like you will have a holiday category and a closed category. I don’t even think a new column will be needed. Can instead use the ‘pc_cattype’ column.
Use 2 for the Holiday category
Use 3 for the Closed category
Then don’t need to hard-code the category id and can instead use above setting to drive the behavior of the category.
We want to make the categories as compatible with postcalendar as possible.
Basically PC should see a Holiday event as full-day event in Holiday category.
This mandates use of a pre-defined category.
The event should not be related to Provider or Patient and there may be more that 1 holidays in the same day. Right now display of full day events takes the whole column. We’re thinking of refactoring the display of full day events to look more like contemporary calendars (on top of day column).
Note that by using pc_cattype instead to store whether it is a 2->‘Clinic Holiday’ or a 3->‘Closed Holiday’ also then allows adding different holiday/closing categories if needed (Religious vs. Government vs. US vs. Israel vs. other holidays etc. that could then be easily turned on/off via the pc_active flag).
Your feature will be very useful and look forward to reviewing it. Just let us know when it’s ready for a code review.
Eventually someone will surely want to replace the calendar with something else.