both of these modules have large issue queues and certainly should welcome any extra help on them

what would be the greatest disjunction points?

IMO they have a lot in common and they differ in many features the other one might welcome.

I just detect an actual design discrepancy that would require some rethought:
- support module uses clients/tickets while casetracker uses projects/cases

I think a re-design might be accomplished:
- merging tickets/cases into one same thing (doesn't seems to be a huge design refactor)
- merging clients/projects into one same thing (this would be the big deal, explained bellow)

Is nice to have issues related to projects as well as having them related to clients
actually, casetracker might be used creating a project for each client the same support might be used creating a client to represent each project
A more complex solution would be considering both, but that would add an extra burden with a client-project-issue relationship

Nevertheless, lets say it is just a matter of projects/issues and projects support nesting (hierarchies)
Then top level projects might represent clients which would be sub-divided into sub-projects with as much nesting levels as desired.

Otherwise, if neither of these module would want something like that it would be just a matter of enabling the desired top level content type. Meaning the same system (API) would be able to work with projects/issues OR clients/issues, which will be determine by the user upon enabling the merged module with resulting sub-modules.

Does this sound like non-sense?

Comments

jeremy’s picture

Status: Active » Closed (won't fix)

Sorry, merging these modules is not on my roadmap -- the support module does what I need. Short of someone contributing patches / stepping up to drive this effort it's not going to happen. Marking as won't fix.

arhak’s picture

BTW, this was addressed by comment_driven