Re: [Phpgroupware-developers] addressbook model and integration with accounts

[Brian Johnson]

Alex Borges (address@hidden) wrote:
>
>This brings another issue up (this is a great discussion). You need to
>ensure no user can delete a company directory contact (this doesnt mean
>that contacts will be eternal, in ten years youll need to lay off
>someone and stuff).
>
>The way i do it, is to have a user be the owner of it and give only read
>permissions from him. But with this new schema, im not shure if this
>would be the best way. The advantage i see to this approach (namely,
>assign ownership to a given user of company directory contacts,
>identifiable by the fact that they will have a non-null value in the
>account_id field), is that then ACL applies as is and we dont have to
>think about a better solution (damn, did i just say that?). I think some
>applications use this approach (projects needs certain groups to work
>fine, i think) and its not such a bad idea.
>
>So i propose to make an admin section for the central directory where we
>could assign ownership of all company directory contacts to a user of
>the admin creation, optionaly autocreating it. Then we could assign
>exactly the permissions you need.
>
>
>
>El mar, 01 de 07 de 2003 a las 10:47, Brian Johnson escribió:
>> Maybe I need to explain more.
>>
>> I'm hoping to link to addressbook contacts for projects in timetrack for use 
>> in
my
>> company.
>>
>> Those contacts are then business records that cannot be allowed to be deleted
>> regardless of how stupid the user is .. it can't even be an option
>>
>> I would prefer that the addressbook simply post a message that app x has a 
>> record
>> linking to the one they're trying to delete
>>
>> The user would then be able to go to that app and delete that record if they 
>> have
>> permissions to do so and then go back and delete the addressbook contact.
>>
>> In your scenario, my app would require a method to cope with the user's 
>> request
that
>> would then recreate the record they just deleted.  It means that all of these
>> changes to addressbook would still render it totally useless to timetrack.
>>
>
>I really dont follow. Would the above solve this? Simply, the users
>wouldnt be able to delete any contacts owned by this particular user im
>talking about. Now, it may be the case that some of this contacts are
>not phpgw users (some are orgs), but you could just make them belong to
>this user (i call it the addressmaster) and the same set of permissions
>would apply.

Umm, sorry, no.

Your solution would mean that all contacts would have to be entered (and owned) 
by
one user.  I currently have about 3500 contacts and we add about 500 a year.  I
need to allow all users to add them, edit them, and delete them.

But as soon as I have a project linked to one, it can be allowed to be edited, 
but
cannot be allowed to be deleted (I'm sorry but I don't know of a better way to
explain this)

To use your solution, I would have to make timetrack modify the owner of the 
record
to the one that doesn't allow other users to delete it .. messy to have one app
changing the records of another app

>
>> I can't believe that timetrack is the only app that has this requirement.
>>
>> That however brings up another point for addressbook.  I need to keep contact
>> information for linked contacts, even if the contact no longer exists (ie 
>> person
>> dies or org goes bankrupt or bought out by another company).  I can use
categories
>> to designate those ones as obsolete, but it would be convenient if the
addressbook
>> ui had a user pref for default filter so that only some categories would be
>> displayed by default in tables, etc
>
>Sounds cool. Very usefull.
>
>>
>>
>>
>> Dan Kuykendall (address@hidden) wrote:
>> >
>> >Brian Johnson wrote:
>> >> what I would like, instead of a way to allow timetrack to handle a deleted
contact
>> >> record, is simply to prevent the deletion of that contact record (maybe 
>> >> with
an
>> >> error message saying what app is linking to the contact record)
>> >>
>> >> I think this would be the easiest to implement too
>> >>
>> >> my main need is to prevent deletion, not cope with it
>> >
>> >Yes and no. We should msg the user that the record is needed by x app,
>> >and then if the user still insists on deleting the record, then x app
>> >would need to have some way to cope with it. Maybe simply deleting all
>> >of its associated records. The msg is all we can do, we cant really
>> >prevent users from being stupid, and in some cases its even possible
>> >that they know what they are doing.
>> >
>> >Dan
>> >
>> >
>> >
>> >_______________________________________________
>> >Phpgroupware-developers mailing list
>> >address@hidden
>> >http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>> >
>>
>> --
>> Brian Johnson
>> * This is where my witty signature line would be if I bothered to edit this
line :) *
>>
>>
>>
>>
>> _______________________________________________
>> 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
>

--
Brian Johnson
* This is where my witty signature line would be if I bothered to edit this 
line :) *