Expanding on department_id usage

["Gerald Chudyk" <..hidden..>]

Hi everyone,

I need to restrict access to specific order and sales records based on
location. A branch location needs to record sales orders and collect
receivables. A branch should not have access to corporate information
(such as g/l), or other sales/ar info specific to other branches. The
corporate office, on the other hand, needs full access to everything.

Within LSMB, normal menu restriction rules are sufficient to prevent
access to complete modules, such as General Ledger. A problem arises
when a user is given access to a specific module such as oe, ar, or
ap. Once admitted to the module, a user may browse all records in the
system.

I have been looking into department_id in the current db as a means of
managing branches within the existing source. At present the default
department_id appears to be a numeric value of zero. This field is
found in the following tables: ar, ap, gl, oe, dpt_trans, and
department. It does not appear to be used in most data entry and query
screens. I have only had limited success in understanding its use
within the code base.

If the department_id field is not in current use:

I am proposing to use the department_id as an information delimiter to
manage access to sales and customer information. To accomplish this I
would need the addition of a department_id within the employee record,
as well as many business rules, and oe, ar, ap screen sets.

My thinking is that the existing screen sets would allow full access
to any user in department zero (the current default value) and
restrict access to users matching department_id for all other
situations. This would provide for an unchanged user experience in
situations where departments are not used.

If a user id is part of department_id zero then they will be given
full access to data records. If a user id is assigned a department_id
greater than zero then they will be restricted to records that match
their department_id value.

During data entry, data records would be created with the same
department_id value as the user id which created the record. If the
data entry was performed by a user with department_id zero, then the
department_id  field should allow editing of its value (possibly
assigning the data entry transaction to another branch).

My proposal does not include inventory balances. Every user id should
be capable of viewing all inventory information.

Chris referred me to Form::run_custom_queries() which I reviewed and
quickly became confused. (I think my lack of Perl skill is showing
again.)

Does this proposal have merit within the existing 1.2 code base?
Should it be deferred to the much anticipated 1.3 code base (and if
so, how long might that be)?

I am beginning to doubt my ability to achieve the above changes on my
own. What could I expect these changes to cost if contracted to the
LSMB team of experts or a third party?

I have both written and reviewed this email before sending, therefore
I am certain I have worded something poorly, or missed something
important. Your comments are appreciated.

Regards to all,
Gerald.