OVPMS-1501 - RabiesTags
Submitted by Ben_Charlton on Sat, 01/11/2014 - 08:46
I am wondering why this was added to the core distribution.
If I am not mistaken its a localization - which we have resolutely maintained is something that is changed at the implementation level...
Adding an identity is just clutter IMO to most practices that have no requirement for Rabies Tags.
I think there needs to be a clear delineation that if a practice wants a custom archetype they need to implement it locally...
Country based localizations could be created but they would be a different package. Once you include one countries localizations then you haven't got much of an argument for excluding another.
Sincerely Ben
Re: OVPMS-1501 - RabiesTags
I've commented it out in the release; practices wanting the functionality just need to edit party.patientpet.
In general however, we should support localisation in order to make deployments simpler in other jurisdictions.
Re: OVPMS-1501 - RabiesTags
Localisation - Localization - there really is a very fine line between tweaks and localisation. In our case, with some 33 customised archetypes, some of the modifications are for localisation (eg no tax so hide tax field), some are for improved funtionality (eg make product description writable and re-title as 'Description/Notes'; adjust transaction descriptions to display useful information).
The wonderful thing about OpenVPMS is that it is so adjustable. The reality is that to get the best from the system needs a significant amount of work and expertise. Its a bit like cars - if all you want is a daily drive, then no work is needed, but if you want to excel at Bathurst then much work and skill is required.
Although it would be nice to have the equivalent of the Economy/Sport/No Traction control switch, the reality is that for optimised use for a given practice, one does need hours in the workshop fiddling under the hood.
Regards, Tim G
Re: OVPMS-1501 - RabiesTags
I have to agree Tim, I think its important the base or core package include just that. To some extant while it would make my job more difficult I can see a case for stripping out the already included Australian localizations. taking the core back to bare minimum and supplying an additional installation package - call it the Australian.zip it might contain custom archetypes, it might contain custom reports and custom sample data. It might even contain a custom war.
The point is you dont get anything your locale doesnt need. Implements can just add stuff they dont need to spend time stripping back an already localized product.
Ben