Hello All,
I am new to SuiteCRM development but do have some experience in building software.
Environment:
SuiteCRM version > 7.11.5
PHP - 7.2
I am trying to implement a new distribution method algorithm (other than the ones that exists).
I have looked and debugged the code to understand the following:
Will need to create a field in the InboundEmail detail and edit view pages to add the new distribution method.
The cronjob & scheduler fires the “Check Inbound Mailboxes” calling into function:pollMonitoredInboxesAOP. This actual distribution method & assignment to the user is done in AOPAssignManager.php.
So as per my understanding, most of my changes are going to localized to AOPAssignManager.php file.
Anyways, here are my questions:
Going through the documentation available, I have not found any information about “how-to” extend the distribution methods and keep it upgrade-proof. The modifications needs to be implemented mostly in AOPAssignManager.php and _AddJobsHere.php.
Is there an upgrade proof way of extending the distribution method? If not, your “guru-level” recommendations of “how-to” implement, deploy and manage this will help.
There are 2 functions, pollMonitoredInboxes and pollMonitoredInboxesAOP. Why use pollMonitoredInboxesAOP from the scheduler job instead of pollMonitoredInboxes?
Please do let me know if you need any more information.
Thanks in advance.
Maybe a nice preliminary question is: which distribution mechanism are you implementing? Do you think it is generic enough to be of interest to other people?
If so, you might be better off implementing this as a change to core, and contributing it on GitHub. This would avoid the hassle of looking for upgrade-safe mechanisms (which I suspect might not be too easy in this case)…
Assign cases only to logged-in users. This needs to be applicable to all distribution methods that are available. This might be of interest to many others as well. This is to make sure, in a support scenario, assign cases to only the people who are working and on the floor.
Assign a priority field to each user in a security group. And assign cases based on this priority field. Am not sure if this generic enough that others might find it helpful.
Please let me know if you need any more information.
I can see other people making good use of both mechanisms.
The priority maybe needs to be a priority of the User itself, not of the user-as-member-of-a-security-group. Even if later you assign the cases based on group membership.
So if you think of making these changes directly in core code, does that make it more straight-forward for you?
Yes, it does make it straight-forward if I can make the changes in the core code. And I would love to contribute to SuiteCRM code
And, yes, your suggestion of priority of the User itself would work too.
Will need to get this done in 2 phases:
Assign only to logged-in users - start with this
Assign based on User priority - will take this up later
As I am new to SuiteCRM code base, I had a few questions, for the logged-in users case, especially if it needs to get into the core code:
Context: Based on my thinking, I’ll need to implement after_login & before_logout logic-hooks from where we will set the logged-in state changes for every user. The User will need a new field, where the logged-in state is stored. And both of these need to be present which is then looked up in the assignment code to make the assignments itself. So we need 3 pieces to be part of the core code, a) hooks b)logged-in state db field & c) the code to make the assignment.
logged-in db field - Right now, I have it as a custom field in the users_cstm table. Should this field now get into the users table?
logic-hooks - Will need to get these hooks into the core code, right?
Will all these changes then need to be done on the AOP module as well, as that also has the distribution method settings.
Question from my earlier part of the thread - There are 2 functions, pollMonitoredInboxes and pollMonitoredInboxesAOP. Why use pollMonitoredInboxesAOP from the scheduler job instead of pollMonitoredInboxes?
What is the code-review & merge process?
What is the recommendation on the unit tests for getting code into the core code?
Maybe you can avoid Logic hooks if you are working in core. Hooks are extension mechanisms, more intended for customizations. But it’s possible that they might make sense in this case, I don’t know. But if you find a more direct place to set your code, maybe that’s better.
I will look into the issue of determining “who is currently logged on”, I will let you know if I can find out something.
have a look at the “tracker” module and “tracker” table in the DB. This is the established mechanism to register user actions. I don’t think it currently handles login and logoff actions, but it could be extended and I’ve seen people asking for this.
not everybody logs off. Many users just wander away from their PC’s, close the tabs, etc. This doesn’t help.
So I asked one of our developers about this and he mentioned this AFK (away from keyboard) mechanism:
