Re: [Phpgroupware-developers] RFC: Addressmaster

[Brian Johnson]

Dave Hall (address@hidden) wrote:
>
>Brian Johnson <address@hidden> wrote:
>
>> I can understand how people would want the system you describe
>>
>> However, it still relies on one or more people having access to ALL
>> of the info or
>> NONE of the infor
>
>No you can have multiple groups with access to change the info.  That
>way IT can change the IT related info, HR can change the HR info.  It is
>a case of business rules.
>
>>
>> I want people to have edit access to only thier own info
>
>For larger organisations this is not a useful solution.  Imagine trying
>to track changes for say 500 people, becomes impossible.
>

I think you are agreeing with me .. it is easiest if they change their own info


>>
>> Since you are working on coding this anyway, would you be so kind
>> as to create a
>> system config name and wrap your functions with an if statement to
>> not run the
>> addressmaster code if the system config variable is set?
>
>16RC2 will be out before I go to bed tonight if all goes well.  We have
>to end the feature creep which is occuring in this branch.
>

wrapping ceb's code in if() statements if it is part of RC2 should be no issue 
since
she is in there and is familiar with the code

the rest I would do for HEAD


>
>>
>> I will edit the admin, system config screen to provide the option
>> to set this
>> variable, create the delete_addressbook hook code to prevent the
>> proper records from
>> being deleted (to run only if this variable is set), and create the
>> code to assign
>> new account contact records to themself (again, only if this
>> variable is set)
>>
>>
>>
>>
>>
>> address@hidden wrote:
>> >
>> >heya,
>> >
>> >i think is the best solution is to have the admin(s) of an phpgw
>> install>choose the addressmasters, including the possibility to
>> have a whole group
>> >- so their members -  as addressmaster. this way our users can
>> decide by
>> >themselfes who should maintain the accounts contacts data.
>> >
>> >i think its not really handy to just have one account called
>> addressmaster>to maintain the accounts contacts data. you every
>> time would have to
>> >logout and login again to change something on these data. isnt
>> >professional imo :)
>> >
>> >i would use acl to handle the addressmasters in a way to have as
>> >acl_app=addressbook, acl_location=addressmaster,
>> acl_account=$account,>acl_rights=read+add+edit+delete.
>> >
>> >the accounts data in contacts have the owner -3, where we would
>> have to
>> >check, if $current_user is in the addressmaster array.
>> >
>> >||cw suggested to just have the admins of phpgw also be the
>> >addressmasters, what would be a reasonable solution as well, imo.
>> >
>> >grtx. ceb
>> >
>> >On Tue, 28 Oct 2003, Edgar Luna
>> >wrote:
>> >
>> >> Hi,
>> >>
>> >> Seems that is not possible for me, maintain this discussion on
>> >> irc. For this I send this mail te begin a threat with all people
>> that>> is interested on the topic.
>> >>
>> >> The new contacts backend will include the `contact' information
>> of the
>> >> accounts, so the apps could safely use contacts to:
>> >> - List of possible member of meeting
>> >> - Adding an infolog item
>> >> - Sending a mail/message/whatever.
>> >>
>> >> We call "system contacts" to contacts that hold the information
>> of one
>> >> account.
>> >>
>> >> There is no problem here and the code is done and working.
>> >>
>> >> The problem becomes in the way that we could distinguish between
>> >> system contacts and the others contacts. This includes the way
>> that we
>> >> go to handle the ACL for system contacts.
>> >>
>> >> Now I know about two ways to handle this.
>> >>
>> >> ,----
>> >> | Basically from ceb:
>> >> `----
>> >>
>> >> We have and addressmaster configuration, with the list of
>> >> addressmaster(s).
>> >>
>> >> Then we have an acl_app=addressmaster, which grant access to
>> >> anybody. in the way that it needs.
>> >>
>> >> Then we have a form that select who are addressmaster (we call this
>> >> accountmaster form).
>> >>
>> >> All the system contacts records, have the owner with value -3,
>> so in
>> >> this way we could check that they are system contacts.
>> >>
>> >> The changes of acl are indifferent from who is the addressmaster
>> >> (killer feature imho).
>> >>
>> >> Advantages:
>> >>
>> >> - We could have N admins with the role (plus admin) of
>> addressmaster,>>   so any of this admins could do changes on that
>> records.>> - This will not affect the acl of this user (ie. he
>> don't need to
>> >>   share his addressbook to be the addressmaster).
>> >>
>> >>
>> >> Disadvantages:
>> >>
>> >> - This add acl checking on all addressbook.
>> >> - ...
>> >>
>> >> ,----
>> >> | Basically form lex:
>> >> `----
>> >>
>> >> We have a user who is the owner of system contacts.
>> >>
>> >> In configuration we maintain the addressmaster setting with an
>> integer>> with the account_id of the addressmaster (this could
>> allow that
>> >> addressmaster be a group).
>> >>
>> >> This addresmaster value in config, will be the same that used in
>> the>> owner field of system contacts records.
>> >>
>> >> This user is planned to be an system account, not really for use
>> >> phpgw.
>> >>
>> >> Now for this we could use the accountmaster form, to (both of
>> them):>>
>> >> 1) Set the addressmaster (the id that will be used on config and
>> the>>    owner field).
>> >>
>> >> 2) Select all the admins/user that have write perms for systems
>> >>    contacts records, so they could edit the information too
>> (well I
>> >>    think so).
>> >>
>> >> The problem becomes on changing the addressmaster:
>> >>
>> >> - What to do with acl? transport the actual state of acl to new
>> >> addressmaster?
>> >> - This is really unnecessary, and must be impossible to do for
>> user?>> Because addressmaster is just used for owner field, nothing
>> else, so
>> >> we must encourage to use a separate user, then we set the list of
>> >> addressmaster with the second box, who have write perms on the
>> record.>>
>> >>
>> >> Advantages:
>> >>
>> >> - No acl changes on addressbook.
>> >>
>> >> Disadvantages:
>> >>
>> >> - The addressmaster must be a user that will have accounts perms
>> >>   limited by his role of addressmaster.
>> >> - For setting who can read system contacts you need to
>> logout/login.>> - Possible confusion allowing change the
>> addressmaster.>>
>> >>
>> >> I want that people that is interested talk and decide what to do,
>> >> thinking on terms of time, usability and usefulness.
>> >>
>> >> Best Regards
>> >>
>> >> --
>> >> Edgar Antonio Luna Díaz - http://www.sogrp.com
>> >> Fingerprint: C008 5EAC 5272 AC8C 7589  4821 8B34 6166 8733 8310
>> >>
>> >>
>> >> _______________________________________________
>> >> Phpgroupware-developers mailing list
>> >> address@hidden
>> >> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>> >>
>> >
>> >
>> >
>> >_______________________________________________
>> >Phpgroupware-developers mailing list
>> >address@hidden
>> >http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>> >
>>
>>
>>
>> _______________________________________________
>> Phpgroupware-developers mailing list
>> address@hidden
>> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>>
>