errbit/errbit — pull request #774 by arthurnn (2014-12-24 03:16:44+00:00)
Title: Refacorting issue tracker

### Problem
There was a few fundamental decisions on the issue tracker plugin that didnt make sense, I will explain them and my solutions.

- Interactor pattern is just an over abstraction that is not necessary here, I replace the `IssueCreation` Interactor with a `Issue` plain model. That has a `save` method, and knows how to call-out the service to create the issue.
- `create_issue` plugin API, was receiving 2 models, `Problem` and `User`, like that we are highly coupling the plugin with errbit core, coupling those two together is not the end of the world, but we have no way to test the other side properly if it depends on outside models. (we need to stub a bunch of stuff, which is not good). Now `create_issue` receives the title, body of the issue, and the user as a hash.
- `body` and `title` generation, should definitely not happen on the plugin side. We should render that body on errbit code (as we know all the models and helpers) , and pass that body to the service only. Also storing all templates (https://github.com/errbit/errbit/tree/master/app/views/issue_trackers) in errbit code, is a bad idea, we should merge all in one, and have one main default body for creating an issue, not depend on the backend issue tracker.
- Fake Issue Tracker should not be in the plugin side. This is just a mock model, only for testing, so that should live in errbit side, and ideally we should only interact with that mock object, and never call out and actual service. thats why I removed the tests from `spec/controllers/apps_controller_spec.rb`

This PR, is not ready to merge, as there is a few TODO in the code yet, but I am sending this so you guys can have an idea that I am working on it, and validate what I am proposing.

@shingara @stevecrozz your thoughts are really important here.