Helen, The problem of restricting access to different types of data - not really addressed in ebase v1 - is one of the great new features in ebase 2.0. You can set privilege levels for different accounts so, for instance, payment info is accessible to development staff, but not to advocacy staff or volunteers.
Soon you'll be able to look at the preview version of ebase 2.0, test it out, and see if it might solve the access issues you've described. Liz ---------------------------------------------- Liz Gans Director, ebase Community Support TechRocks 432 Last Chance Gulch, Ste K, Helena, MT 59601 406.442.0082 [EMAIL PROTECTED] ---------------------------------------------- > -----Original Message----- > From: Dave Shaw [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, September 19, 2001 10:49 AM > To: TechRocks Support > Subject: [support] Re: Multiple programs using database(s) > > > >We have several programs in our organization with various levels of > >affiliation who all currently have FileMaker databases. Our central > >administration has gone to FileMaker/ebase 102 and now the > question is > >whether to incorporate the program databases into the > central one. The > >conventional wisdom among ebase users/trainer seems to be that one > >database per organization is best and, I agree that there > could be lots > >of wasted opportunity and/or duplicated effort if, for instance, one > >program has info on an activist's interests that other programs don't > >have access to. > > In addition, you'll likely have duplicate records among the several > databases that all need to be maintained with address changes and the > like. > > >But there are potential problems. We don't want all > >the affiliated programs to have access to giving history > information to > >the central organization. Is there a way to block access to this > >information? Any other suggestions? > > There is always a way. But in this case it's not built in to ebase, > and is very complicated to implement. You would need to change the > password structure of the ebase file set to allow access to payment > records only to selected access groups. Further, you'd need to > restrict access or modify layouts in other files where payment info > is presented. For example, the home screen contains payment summary > info for the current and last year, and membership info, all of > which you would presumably want to restrict. > > Another strategy which might be simpler although a little more > cumbersome, would be to create a rolodex file which gets updated > periodically by exporting contact info plus whatever activist info is > relevant from ebase. It would be easy to script this so the update > would be called by one button click. What do wouldn't get with this > is the ability to track contacts and actions with ebase that seems to > me would be valuable to your programs. > > Anyone else have a strategy? > > -- > -- > Dave Shaw H4 Consulting > tel: 206-954-7526 fax: 206-625-1338 > > ------------------ > Reminder to each recipient: To change your list account > preferences, go to > http://email.sparklist.com/scripts/lyris.pl?enter=support > and enter the email address you used to subscribe to the > ebase support list:: [EMAIL PROTECTED] > > To unsubscribe send a blank email to > [EMAIL PROTECTED] > --------------------------------------------------------------------- > ebase - Relationship Management for Nonprofits, http://www.ebase.org > --------------------------------------------------------------------- > ------------------ Reminder to each recipient: To change your list account preferences, go to http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email address you used to subscribe to the ebase support list:: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] --------------------------------------------------------------------- ebase - Relationship Management for Nonprofits, http://www.ebase.org ---------------------------------------------------------------------
