Re: Non-profit/Campus Management Expansion for LedgerSMB?

["Chris Travers" <..hidden..>]

On 10/18/07, Chris Nighswonger <..hidden..> wrote:
> On 10/18/07, Chris Travers <..hidden..> wrote:
> > I am going to reply to both here.
> >
> > On 10/17/07, Chris Nighswonger <..hidden..> wrote:
> > > General:
> > >    Fund/Non-Profit Accounting (There are some stirrings on this I think...)
> >
> > Something that would really help would be a few scenarios of
> > transactions and how they map to designations and accounts.
>
> I'll try to get the accountant into this discussion.
>
> >
> >
> > >    Facilities Management
> > In this as in most areas, the key is going to be understanding the
> > problem.  I would suggest that in each of these areas you may want to
>
> ...elaborate.... (I assume :-)

Basically  we need elaboration of the issues :-)

>
> I suspect that this is a combination of code/administration like the
> ssl issue we hashed out in another thread. However, such a module
> should provide the ability to secure such data at the necessary level
> or at *least* be flexible enough to adapt. In my understanding the IT
> side of HIPPA is largely securing the data itself and access control
> to the data on a need-to-know basis. Again, the level of compliance
> will be dictated by the *type* of medical data to be stored.

This would tie you to Linux, but you may want to take a look a
se-postgresql.  It would seem to have the framework you need for
access control.  Of course the price of doing a security check on
every row may limit performance.  se-postgresql appears to still be in
beta, but the idea is that you can assign SE-Linux security policies
to tuples, tables, columns, etc.


> Understood and agreed with as an issue with larger business types. I
> do not perceive this type of issue in our situation. However, I can
> see how this would be an issue in a context where departments are more
> numerous and less adept to cooperate with this sort of thing.
> (Microsoft uncooperative??? :-P)

Basically, what it comes down to is don't try to shove everything
through the same interface or client app :-)

>
> > I think that basically you have two options going forward.
> > 1)  You could look for other programs that do most of what you want
> > them to do
>
> I have looked at CiviCRM. My concern is MySQL. If we are going to run
> a patch work of apps, a common db would be nice.
>
> Until this post, I was unaware of Koha. Took a cursory look at it and
> was impressed.
>
> >and port them to use the common LSMB framework (CiviCRM,
> > Koha, some EMR solutions, etc).
>
> I assume this could be done with some custom code, sp's, and triggers.
> (ie. transaction in one app triggers sp/code which manipulates data in
> another apps db/table(s) etc....)


Basically my idea is to try to leverage other projects as much as you
can, and rewrite the database access components to work with the main
database that will store everything.  Basically have a single common
db with multiple client applications.

>
> With membership/donations/library/academic records/etc. we really need
> to achieve a SPOE for common data such as members/entities, etc. Users
> will scream if they have to do double entry...
>
> >
> > 2)  You could build up add-ons in a modular and modetely coupled way--
> > each being a new client application to the LSMB database.
>
> If #1 is the most straight forward approach, it wins in my opinion. No
> need to reinvent the wheel. Although as an admin, I am partial to a
> common db rather than db's of different flavors. Its more to keep up
> with from a maintenance/security prospective.

The approaches are not even mutually exclusive.  Nothing prevents you
from, say, coordinating with Koha and sharing at least part of hteir
codebase.  The big disadvantage of going with things like CiviCRM and
portng them to the LSMB db is that you are going to run into the fact
that now you have to maintain software in multiple languages (PHP and
Perl.  Now go ahead and add GNU-Med for accademic records and you get
to maintain software in Python too. )

> > > I would like to hear what others want/need or would like to say
> > > concerning these items both from the user and development standpoint.
> >
> > If it would help, I will throw the idea at another school and see if
> > we can get something going here.  One area I could see helping would
> > be fundraising auctions.
>
> It would be nice to here another school's thoughts/input.
>
Will do.

Best Wishes,
Chris Travers