Alternatively, the members plugin could be aware of the presence contacts plugin and have a button that generate the contact. Or perhaps all the "members" would automatically be added into "contacts"? Do you have categories of contacts?
The contact would by default be synchronised with the members data (the member update could announce some kind of event). Then in the contact plugin interface, a checkbox would let you turn on or off synchronisation with the members data. -----Original Message----- From: S.Isaac Dealey [mailto:[EMAIL PROTECTED] Sent: Monday, 12 September 2005 6:01 a.m. To: CF-Talk Subject: Interface Question So I'm planning to build out a contact-manager plugin for the onTap framework. This plugin will allow people to manage multiple address books each of which can be declared private or public, with selection criteria including language/locale, company, location (i.e. Downtown Office), arbitrary regions (provided in the Members onTap plugin), etc. with custom rules for determing who can do what with each address book. None of which has anything to do with my question. :) The Members onTap plugin maintains an email address for each application member. I've always hated needing to update lots of different coppies of an address or phone number when someone moves, etc. so I'm thinking I'd like to provide some integration between the email address stored for the member (where forgotten passwords and system notices are sent, etc) and the email addresses stored in the member table. My problem is that I'm not sure how to design it in terms of user-interface/usabiliy. I've considered three things: 1) update the contact system automatically when the member email address is updated (though a member may update their member system-notification address without wanting to change their "public" email address) 2) update the member system automatically when a matching contact email address is changed (though again a member may want to change their "public" address without altering their member address for system notifications) 3) present a list of contact names/addresses in page, which could be changed when changing a member email address 4) ask the user in-page if they want to change the member address when they change a matching address in the contact system 5) send an email to a member when a matching email address is changed in the contact system to remind them that their member address hasn't been updated All of these potential solutions, in addition to producing more user-interface questions (or potential annoyances) also carry with them a number of security implications / limitations. A member who has permission to edit contact information may or may not be able to edit member accounts, so there's some question as to whether that should also apply to the email address? And the inverse is also true that a member will always have permission to change their own email address, although even if a person has permission to edit member accounts that doesn't necessarily mean they have permission to edit contact information for a particular address book (i.e. a client may be allowed to manage the member accounts for their own employees - that doesn't give them rights to edit another client's address book). Thoughts? Thanks, s. isaac dealey 954.522.6080 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://www.fusiontap.com http://coldfusion.sys-con.com/author/4806Dealey.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:217903 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54