> > > The issue says: > > > > > > If a User Group is created for IM users we should add by > > > default > > > the Personal assistant IM User, "MyAssistant", to that IM > User > > > Group by default. This would save every IM user adding the > > > "MyAssistant" PA IM user as a buddy > > > > > > I don't think this is a good way to solve that problem. > > > > > > Putting a user into a group affects more than just whether or not > that > > > identity is allowed to send me messages - it also affects where > that > > > user appears in my buddy list. The users that appear in the > > > server-defined groups cannot be moved out of those groups or > hidden. > > > > > > Conceptually, the MyAssistant is not in fact a member of those > groups > > - > > > for example, in our alpha trial system I'm in a server-defined > group > > > "SCSDesignTeam" - MyAssistant is not a member of the SCS Design > Team, > > > so > > > having it organized in my buddy list as one is unhelpful. > > > > > > I don't see why the problem of allowing the MyAsssistant bot to > send > > me > > > messages shouldn't be handled in exactly the way letting any user > send > > > me messages is handled - it requests permission and I grant it > through > > > my IM client. At most, we need a button in the user portal I can > push > > > to trigger the MyAssistant asking for that permission. > > > > > > > I think the most important "use case" we need to deal with is to > > simplify the administrator task of adding Personal Assistant to a > group > > of users. It would not be optimal to make people have to add a buddy > for > > this. At least with Pidgin this is a bit of a pain. In short for me > my > > vote is.. > > > > Make it simple for the Admin to deploy.... > > Fine... make the setting work at the group level - but that should not > actually cause the Assistant identity to be a member of the group. >
Sorry I will bite.. How then does the admin get a user to have this appear? Are you suggesting we require every user who wants to utilize this feature to do some action? _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
