phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Borges
Subject: Re: [Phpgroupware-developers] addressbook model and integration with accounts
Date: 01 Jul 2003 12:41:50 -0500

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.

> 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
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]