(moving to dev list) Wayne
My biggest fear is that If we were to implement data level permissions it would slow the system down significantly. Data level permissions starts off easy: Restrict patient with location = X to users with privilege can_see_patients_at_location_x However, making that generic gets complicated: restrict table y where column_z = X to users with privilege can_see_table-y_where_column_z_is_X I'm sure there would be a way to store that so that an admin can specify that. However, we'd then have to modify all core api calls to obey that principle. Reporting would be the real slow-down. If we could identify the 90% use-case for data level permissions that might be doable. How would you be using it? aka what are you restricting, when, and to whom? Examples: 1) Provider at hospital Y can only see patients if they have ever had an encounter at location Y (if making most generic: how to know if a provider is "at" hospital Y?) 2) Provider of specialty A can only see patients if they have had an encounter with encounter_type A, Aa, or AAa 3) User can only see data that they are the "creator" of Ben On Wed, Apr 18, 2012 at 12:54 PM, Wayne Chelliah <[email protected]> wrote: > Hi Ben > > Just following up on our conversation from last week. Can you please help > me understand what are some of the specific challenges with the OpenMRS > architecture that make data level permissions difficult? > OpenMRS can use roles and privileges to restrict access to pages, forms > and encounters. But can we restrict access to groups of data that span > multiple encounters? > > Regards > Wayne > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
