Summary:	ASTERISK-00150: Update app_directory to support MySQL (like vmail2) and Last and/or First option switches
Reporter:	scrubb (scrubb)	Labels:
Date Opened:	2003-08-22 11:42:10	Date Closed:	2004-09-25 02:49:15
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Now that Voicemail is being depricated in favor of Voicemail2, and Voicemail2 can be run out of mysql, app_directory needs to be updated to support mysql in the same way as Voicemail2.  In addition, I have had many customers who indicated they did not remember a person's last name and wished the directory allowed for first or last name lookups.  This should be fairly simple to add as well.  Sorry for the "double barreled" request, but both should be fairly trivial to do once the app_directory.c is on the operating table. ****** ADDITIONAL INFORMATION ****** I would imaging the option switch would be something like, default is last name only, then Directory(context,[l][f]) where l allows last name matching and f allows first name matching, and lf allows first and last name matching.
Comments:	By: John Todd (jtodd) 2003-09-12 18:09:06 Scrubb - do you have any interest in putting together some patches here for this? By: scrubb (scrubb) 2003-09-14 13:38:08 I have begun reading the code to understand it.  However, my patches will be very slow in comming if I do this.  My dev box will not be free for another couple of weeks. However it is accoplished, I think it would be valuable if the mysql code could be shared between the voicemail2 and app_directory applications rather than a quick and dirty cut and paste of funcitons. By: scrubb (scrubb) 2003-09-14 23:21:09 I've given more thought to how to share a voicemail user api between apps.  I would propose the following idea for loading a voicemail user API as a shared module. Build voicemail user api modules as shared libraries. The Main VM module uses these calls to allow pugins to handle different stores of user data, such as different db's, ldap, etc. In load_module, voicemail2 should read its config which should include a vmuserapi=modulename where modulename is the specific module that will be used to handle voicemail user data.  The default should be vmuapi_file, which behaves exactly as the current non sql api, and the vmuapi_mysql would allow mysql use from both vmail2 and app_directory. vmu_api_find_user called from local find_user vmu_api_change_password called from local vm_change_password vmu_api_reset_user_pw called from local reset_user_pw vmu_api_load_config called from local load_config vmu_api_load_module called from local load_module (dblogin, etc) vmu_api_unload_module called from local unload_module (dblogout etc) vmu_api_getfullname for app_directory compatability vmu_api_getfirstname  " vmu_api_getlastname  " vmu_api_getfield(fieldname) to get any field vmu_api_getfield(fieldname,val) to set any field load_module called on module load unload_module called on module unload Any thoughts? By: John Todd (jtodd) 2003-09-15 12:50:33 Does it make sense to have "get" as the first letters of a routine that both reads and writes?  I'm not a programmer, so don't weigh my comments too highly, but it seems slightly confusing. What are the fieldnames for email address and pager address? Why would the password reset routines be any different than any other get/put to the database or flatfile? While you're in there, maybe you can make the voicemail file write routines also as modular; I'd really like to see voicemail messages pushed/pulled from a database as BLOBs or similar components, so I can distribute voicemail more easily across multiple servers.  My scanning through the code doesn't seem to show that as a feature now, but I could be wrong.  This is really a separate feature request, but I figured I'd mention it here.  :-) By: scrubb (scrubb) 2003-09-15 13:13:41 The second "get" was supposed to be a set, that was a typo. The fieldnames would be the same as what are used in the mysql db, ie email, pager.  I like the idea of get/set and pass the field name so the module does not need to be updated to handle schema changes. The password routine and the get_first/last/full name rutines would essentially be the same as the other rutines.  The reason I seperated them out is that some datastore password rutines may involve encryption or other special handling when setting a password beyond just storing it in the db.  The get_first/last/full name would allow the plugin to decide if the names are stored seperately or if its all one field that needs to be split.  In theory, these all could fall under the get/set field rutines, but I thought they might be a little more programmer friendly all spelled out. As far as the sound file rutines are concerned, I have been discussing the idea of a vmailstore plugin with Mark and #asterisk regulars for some time now.  It would indeed be a seperate feature request, but I would imagine that it would be done in a completely similar fashion, where a filestore API module is specified in the vmail config and the mv/rm/dir commands would be abstracted as API calls. By: John Todd (jtodd) 2003-09-15 22:30:20 I would actually suggest that the filestore configs are stored in association with the user, so that different users can have different storage locations (different databases, different pathname (if flat file))  Would this be just an additional fieldname, or would it be a named field all it's own? How would one store contexts in your proposed structure?  Would they be stored in the voicemail.conf file, or on a per-user basis?  It seems that context would be a key field, since that and the voicemail box number are the two items passed into any voicemail routines (other than the "u", "b", and "s" values for Voicemail2 and VoicemailMain2) As far as passwords are concerned: encrypting passwords seems to be a good idea, though I start to scratch my head when I think about how I would integrate that with a web interface - seems to add another layer of stuff.  It is perhaps sufficient to leave passwords unencrypted: if a user or script can overwrite the user, why hide the password?  In other words, it seems that encrypting the password is a mismatch of security compartmentalization - you've already got "root" if you can read that database, and encrypting the password only adds overhead to any routines that access that field and does not provide any real security. By: scrubb (scrubb) 2003-09-16 22:11:07 I would imagine that we would support a "compatible" file api that essentially acts exactly as the file storage does now, using the voicmail.conf file.  In other words, no really flexible way to add more attributes. I would propose a new "directory" api for configuration for those who don't want to delve into mysql right away.  I would imagine that there would be an /etc/asterisk/voicemail.d/ which contains individual files for each user.  The files can be in the same "config" file format that all asterisk config files are in, "[context]\n key=value".  The files that are in the /etc/asterisk/voicemail.d would be in the "default" context.  Directories under voicemail.d/ would be contexts.  This way an arbitrary set of attributes could be assigned to each user and symlinks could even link the same user into multiple contexts. The above scheme also represents the way different tables in a database could be different contexts for users. The idea is that the voicemail.conf file could contain a "userapi=compatible" for things to operate exactly as they always have.  There would be no per user storage API.  However, a "userapi=directory" would allow you to add a "storageapi" parameter for each user, even users in the same context.  It would even allow "custom" parameters for different applications. As far as encrypted vs unencrypted passwords, the issue could be completely api module based so the decision to obfuscate the password could be a switch on the user property or even if the userapi module supported it. Unless you have some other suggestions I would imagine a timeline like this: -Sometime after the next 2 weeks I get my dev box back. -Start work on the vmuapi_compatible.so module -Modify app_directory to use the new modular vmuapi system -Assuming Mark et al like the idea and it has not segfaulted app_directory back to the dark ages, modify app_voicemail2 to use the loadable api -create a vmuapi_mysql.so module By: Brian West (bkw918) 2003-11-19 19:32:14.000-0600 see bug 457 By: Brian West (bkw918) 2003-11-19 19:33:56.000-0600 Refer to bug 457