Re: [Phpgroupware-developers] Re: addressmaster vs no addressmaster

[Alex Borges]

Yes i remember brian wanted this from the begining. I think there is a
simple enough solution for that. But i wont volunteer to code it.

As the upgrade path and the setup_demo (upgraded and new installs
respectivly) are done, there is a way to identify system contact
information by owner=phpgw_info['addressmaster']. So a button could be
provided in admin to migrate all of that (being it upgraded or created
from scratch) into owner=account_id of corresponding account entry for
person_id. Its one update query.

All the rest is how brian depicts it.... let us see if we can really
spare the time here (jarg, eald, me) to code that feature. If not, we
need a volunteer. Its a good oportunity to learn the contacts_sql code
and the way the accounts <->contacts link work.

All in all i think its a good feature what brian is requesting, although
i think in other terms, i think central repositories for companies
should be kept tightly in sync and controled, or thats how i need it.
Brian, you are lucky u can do that to your users.

Anyhow, to be good enough some kind of link to edit my central directory
information should be provided, thats not complex at, its just a
phpgw->link call.





On Tue, 2003-10-28 at 15:06, Brian Johnson wrote:
> Brian Johnson (address@hidden) wrote:
> >
> >I would like to start discussion about the new addressbook integration with 
> >the
> >phpgw accounts system and specifically the concept of an addressmaster 
> >account.
> >
> >The purpose of this logic (the way I understand it) is to have an account 
> >created on
> >your system (called addressmaster) and have that account own all of the 
> >addressbook
> >records that are linked to accounts in order to control who can edit that 
> >info.  Of
> >course, the acl system would allow the admin to provide edit access to other 
> >groups
> >and users on the system so that other could edit the info as well.  I 
> >understand
> >that ceb is working on some code so that the addressmaster account is 
> >optional and
> >that function can be assigned to any one (or multiple) user or group.
> >
> >I would like to allow each of my users to edit their own information and not 
> >only
> >have read access to the information of the other account holders.  The 
> >current
> >proposed system does not provide for this.  I could provide edit access to 
> >the
> >contact information (linked to the accounts) to the account holders but then 
> >they
> >would have edit permission to the contact information of ALL of the account 
> >holders.
> >
> >The reason I want to set my system up like this is simple, I'm lazy.  It 
> >saves me
> >from having to do it (also I claim I've got better things to do than 
> >continually
> >update people's addresses when they decide to move).
> >
> >Don't think of keeping the information current on a per account holder 
> >basis, think
> >of you, as admin, doing the updating the contact information of 100 people 
> >or 1000
> >people.  Also consider the volume of information that you would be 
> >responsible to
> >keep current, possibly without any formal notice of information change: 
> >business
> >addresses for department changes, title changes, home addresses, cell phone 
> >numbers,
> >email addresses, instant messaging.
> >
> >I think you can appreciate why I don't want to be responsible for keeping it 
> >current.
> >
> >So here is what I propose for discussion:
> >provide a system config option to use the addressmaster concept OR have the 
> >account
> >own the contact record linked to that account (and bypass all of the 
> >addressmaster
> code)
> >
> >I don't think the addressmaster concept can be modified easily to accomodate 
> >what I
> >want (and what I think many others will want).
> >
> >The admin can use the existing acl system to provide read only access (or 
> >even edit
> >access) to the contact info owned by any single account (or admin by account 
> >group)
> >
> >There only needs to be a way added to prevent these records from being 
> >deleted while
> >the account exists.
> >
> >We already have the answer for that too.
> >
> >The new addressbook calls a addressbook_delete hook for any apps to prevent 
> >the
> >deletiong of a record (created so that other apps can use the addressbook as 
> >a
> >contact store without fearing that the info will be deleted by an 
> >unsuspecting user)
> >
> >With this option, addressbook (or phpgwapi) can have a hook that checks to 
> >see if
> >the contact record is linked to from an account (phpgw_accounts is the table 
> >that
> >stores which contact records is linked to that account), and prevent it's 
> >deletion.
> >
> >Even if the owner of the record tries to delete it, it is protected from 
> >deletion.
> >
> >So coding for this entire option may be as simple as creating a config 
> >option,
> >wrapping the addressmaster code in some if() statements to only run if that 
> >option
> >is selected, and a delete_addressbook hook.  Sounds very simple.
> >
> >
> >
> 
> 
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>