Modules: Best Practices, Minimum Required, Etc

General Help
1

Using the latest FreePBX distro (10.13.66-12) and I have been noticing something I just don’t get.

Commercial Modules that require a license to function: Do these do ANYTHING other than provide useless GUI menus and confusion. System Administration module would be an exception as the Commercial License enables additional features. I saw a couple other Commercial modules that do not state they require anything at all to function and do not show the "Buy"
button (Zulu would be one).

I am only using softphones with my installation so some of the other modules like OSS and EndPoint manager are fairly useless to me (unless I am missing something). I use the Bulk Phone Restart module, but every single update script barks about this or that not updating because of this or that module.

For me I am removing all commercial modules that require a license to run, or when you go to their UI within FreePBX you get a message indicating - no license, no workie.

There’s more and these dependencies would be nice to know in advance. I am not afraid of doing a little RTFM, but I am not finding what I am looking for on the documentation WIKI. If anyone can point me in a direction this is what I am looking for:

Module Administration Best Practices - Disable, Enable, Remove. When and why per module. I’m not worried about disk space or running a lean system, I just don’t/can’t use certain default modules, I get it all setup and the update script puts it all back :slight_smile:

Module Dependency Mapping - Which Modules Require Which other Modules. If a “free” module depends on a commercial module and the commercial module requires a license, is the free module actually working?

I am not necessarily looking for specific answers to my thoughts here, I am hoping someone out there understands the general idea of what I mean here.

Thank you for your help in advance.

1 Like
2

I agree. I don’t want to write it, but it would be cool if someone could start the ball rolling with a little WTFM, or in this case, WTFW (… Wiki). If you were to put together some notes on what you’ve found and maybe to give the folks that are “in the know” don’t have to cut this from whole cloth, I’m sure it would get done exponentially faster.

3

Disclaimer: Sangoma Employee

Of course they do. If you have need of the functionality provided, and you wish to use them, that is an option available to you. Many users take advantage of commercial modules.

All modules won’t be useful to all users. I assume this was rhetorical, you don’t expect these modules to be abandoned do you?

Many modules have dependencies. If the dependencies are missing, you can expect notices if you attempt to install. Again, not sure what your expectation is here. If you have specific examples of a module not being installed where you believe it would otherwise work, this may be a bug, but nobody can action a general complaint about barking.

I assume by ‘require a licence’ you mean the module requires purchase, all modules have licenses. Of course, you are free to configure your system as you wish, however, instead of removing modules, may I suggest you instead DISABLE unwanted modules. That way they will not be reinstalled if you choose to use the optional Distro upgrade scripts.

Many modules have dependencies, many have dependencies of specific versions of other modules, there are a few prohibited combinations, and this changes periocically as development proceeds. Module Admin keeps it all straight so you don’t have to. A wiki that attempted to track this info would ALWAYS be stale. To what I believe is your specific concern, I am aware of exactly ONE case where an OSS module has a dependency on a FREE COMMERCIAL module. There is an open ticket for this one case, and there will be a resolution at some point.

This again goes to the difficulty of maintaining a list of dependencies for each and every module. If you attempt to install a module with an unmet dependency, how is the notice in the GUI not sufficient?

Disable and Uninstall are functionally equivalent. Remove is self-explanatory, the code is literally not present on the system. The Distro update scripts will ignore disabled modules. The Distro update scripts are optional, users are free to update their systems manually.

4

Thanks Dave, where would I best send this information? I should have added more detail…might have been more helpful.

5

Lorne,

Thank you kindly for your reply, very helpful and much appreciated. I apologize for not taking the time to detail out what I have been seeing, I was honestly thinking I would be pointed to a WIKI or some other reading materials instead of your helpful reply. Thank you again.

If you don’t mind I would like to get back with a better post - would it be best to try again here or start a new one? If here, would it be best to just edit the original. Looking for guidance here to make this a helpful post.

1 Like
6

Not sure it matters much. If the content of your next post is sufficiently different than what you’ve started here, it probably belongs in a new thread.

7

Totally unrelated but kinda…

The only oss module I can think of that requires a non-oss module is tts. As of today, ttsengines is oss…

1 Like