Re: [Health] Freely configurable Party and Products Flags with Configurable Per-Group Defaults

[Alexandre Santos Aguiar]

Hi,

Em Sex 20 Abr 2012 às 04:27, falava-se sobre "Re: [Health] Freely 
configurable Party and Products Flags with Configurable Per-Group 
Defaults" e Christoph H. Larsen escreveu:
> ad as new medical fields are added over time, you have to be constantly
> on the watch not to expose medical details to clerical staff. (I know

Yep. Think I understand now. Still do not have enough knowledge on Tryton 
but generic system wide methods have been used elsewhere. Just for 
brainstorming. Access privilege is a difficult matter.

One such "generic" method is the use of domains and contexts. Different 
applications of domains define both so that a context is an application 
domain where a given user is in (within his/her user domain). Tryton 
seems to have both already.

If a user can create fields (or objects of any other available classes) 
within his domain then the new fields|objects simply inherit the context. 
This way "roles" can be defined dinamically depending on context even 
without explicit user configuration. The whole system can be yet more 
stringent by submitting functions and whole classes (including interface 
components) to the this "domain + context = role" scheme (I suspect this 
already happens somehow).

The only new function to be created (for human use) is the ability to 
change contexts of newly created objects. And "change" here is the same 
as privilege scalation in an (expected to be) ordered and safe fashion. 
The less human intervention the better, IMHO.

A wider application of the contexts can include the machine where 
application is run and/or the machine that requested data, important in 
distributed applications.

Scenartio: someone creates a field (a database field and a correspondent 
interface in a given window possibly with attached functions to assure 
correction of newly entered data). For instance: a phisiciann creates a 
field to record the presence of say, Naffziger sign. Both objects (data 
colection interface and data storage) inherit the context of a phisician 
caring for patient so that the system unsderstands that non health care  
personel is not to see that bit of information. Not to take into account 
the these new two objects will already be available only in the context 
of a window that is available in the context of an app, etc. This 
approach produces a very strong hierarchical mechanism with many 
redundant such controls so that no single hack can unconceal much 
information. If network location restriction is applied, other effects 
may appear: a phisician could not open patient information (or be 
required to assume himself liable for doing this) in a guaranteed non 
private or non patient related local. This, however, requires a so 
unlikely high commitment of IT personel although could be handled 
(actually completely automated) by proper network topology.

An approach like this is used by Drupal that makes it available to third 
party modules through an API.

Actually, for maximum automation and minimum impact on existing code, a 
static object of class context (or anythigng meaningful) can be a private 
component of a primitive virtual class to be base for all data related 
classes. Or something like this that could work.

Please, forgive me if I wrote too much crap. Still have to study a big lot 
of Tryton/Gnu Health internals. :-)

My 2 cents.


-- 


Alexandre

--
Useless fact for today:
If you feed a seagull Alka-Seltzer, its stomach will explode.
--
All messages from my addresses express my own (often obscure) opinions and 
have no relationship to the views of past|current|future places I work, 
their administrations, employees, my wife, my daughters, the nation, the 
world or the universe in general. Enough?

signature.asc
Description: This is a digitally signed message part.