Suggestion: Improve Coding to allow Enhancements

[markbond1007]

The current expansion framework for SuiteCRM is not bad (particularly the LogicHooks), but parts of it are open to conflicts (overriding PHP sections in the custom/modules folder seems to be potentially dangerous if you end up installing multiple modules).

As such I would like to suggest that the code needs more LogicHooks being fired off in various locations and possibly a greater use of config files for some parts. I do not do huge amounts of development for SuiteCRM but I have seen a variety of places which this would be good.

So combined with this it may be worth setting up somewhere that devs could provide suggested locations for LogicHooks.

Anyway my Contribution (please bare in mind I am aware that we can use custom/ to force override this but am considering that there is the possibility that more than one extension may need this after which it becomes complex):

Action Menus:- Being able to add to the DetailView/EditView by having a Logic Hook triggered and adding to the menu array would be nice!

Calendar/Scheduling:- being able to add a custom module to the list of Bean Types that are checked for meeting conflicts etc. should be easy, but the Bean Types are hardcoded in multiple locations (Calendar.php/CalendarActivities.php/vCal.php etc), having this list extensible (via a .ext file) or via a triggered LogicHook would be ideal.

I am sure there are more places this would be useful, I do hope this is going to the correct place - feel free to close/move it if not.

[pgorod]

Are you aware of the Extension framework?

https://docs.suitecrm.com/developer/extension-framework/#_standard_extensions

Logic hooks are only a small fraction of what's available...

[markbond1007]

@pgorod

I am indeed, and thats part of what I was mentioning above, there are chunks of code (see the bit about the calendars) that are not using the framework and so the only option would be to replace the core code to extend it so a more indepth example for Calendar.

If I want to write a module that adds in a new type of "activity" that is displayed in the calendar, I can do all of this except display it in the calendar and the scheduling lines because all the calls to check dates and times in Calendar/vCal go something like this:

` // get activities.. queries Meetings and Calls $activityList = array( "Meetings" => array("showCompleted" => true, "start" => "date_start", "end" => "date_end"), "Calls" => array("showCompleted" => true, "start" => "date_start", "end" => "date_end"), "Tasks" => array("showCompleted" => true, "start" => "date_start", "end" => "date_due") );

        $acts_arr = CalendarActivity::get_activities($activityList, $user_bean->id, false, $start_date_time, $end_date_time, 'freebusy');
        /`

Both Calendar and vCal use that array in multiple locations (which incidentally must be a code maintenance nightmare).

My Suggestion is to check things like this so it either references the extension framework, so that like AOW_Actions etc you can easily extend the functionality without having to create a new version of (for example) vCal.php in custom/modules/vCal, by having arrays like that extendable. Obviously this particular example can be done either like that or via a LogicHook.

The point really is to have somewhere to register instances like this and have it considered so that sections like this can be safely extended.

[pgorod]

Things can be a bit misleading when discussing customizability. Often the real issue is the non-standard approaches found in some modules, like this one. If things are built according to the official model, then it eventually all boils down to the possibility of extending a class, and overriding a member function, which is already a possibility.

So possibly what needs to be done in many places is just refactor the module.

The two areas where I would like to be more extensible (following our typical extensibility mechanisms) are mPDF and TinyMCE customization. We should be able to use the full customization options that these packages provide, and it should be something we can override in very specific ways (per-module, per-view, per-action type, etc)