The Need:
Our Standard development projects start out with the same handfull of milestones and 50-60 tasks that we load into atrium at kickoff. Here is how we have organized our projects within the Atrium Structure:
1. Group -> Project (Client A Site Redesign)
2. Projects -> Sprints or Milestones (Spec, Design, Config, Dev, QA, Deploy)
3. Cases -> Tasks (Setup dev environment; Generate home page wire-frames, Install cck, etc...)

Instead of re-creating these cases (tasks) manually for each new project, our PMs would like to setup a template in Excel (CSV) and import it in at the beginning of the projects.

We have cobbled together a CaseTracker Template import process for Open Atrium with FeedApi, Feed Element Mapper and a modified version of the feedapi_casetracker mapper (http://drupal.org/project/feedapi_casetracker).

Some of the challenges of this approach have been:
1. We have to use FeedAPI instead of Feeds
2. The Mapper does not have any knowledge of the groups a case should be attached to
3. We have to run a views bulk operation to update the imported cases to the proper group after importing
4. We can not export any of the FeedAPI settings because it is not Features-aware

Suggestion:
Port the FeedAPI_Casetracker mapper to Feeds and include the ability to map the OA OG group on the way in.

Once we can use Feeds and define a feed importer, we can bundle it with some of the other functions into a PM tool kit feature for OA.

CommentFileSizeAuthor
#12 casetracker_826490_12.patch1.28 KBryan.gibson
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alex_b’s picture

I'd encourage you to come up with a general mapper for Casetracker. If supplied with tests I would happily commit it to Feeds.

clemens.tolboom’s picture

This sound indeed great to have available.

But we needs a OG mapper as well.

I'm available to write the code ;) I partly did #623428-36: Provide hook_feeds_user_processor_targets_alter() which was initially a location mapper.

alex_b’s picture

Title: Create Feeds mapper for Open Atrium Cases » Mapper for casetracker
alex_b’s picture

Status: Active » Postponed

Postponing this as nobody's working on this feature.

chitown4’s picture

This feature would be great. Hope someone picks it up again.

ergonlogic’s picture

Status: Postponed » Active

Hi,

My use case is slightly different, but also requires a functional Feeds Casetracker mapper. So I'm taking a stab at this.

Basically, I'm exposing a project via Views XML Datasource, and then using the Feeds XPath Parser to map that onto the various Casetracker fields.

This hook_feeds_node_processor_targets_alter() implementation appears to work as expected:


function casetracker_feeds_node_processor_targets_alter(&$targets, $content_type) {

  $fields = array(
    'pid' => 'Project',
    'assign_to' => 'Assigned to',
    'case_status_id' => 'Status',
    'case_priority_id' => 'Priority',
    'case_type_id' => 'Type');

  foreach ($fields as $k => $name) {
    $targets[$k] = array(
      'name' => $name,
      'callback' => 'casetracker_set_target',
      'description' => t('The Casetracker !name field.', array('!name' => $name)),
    );
  }
}

However, I can't seem to get casetracker_set_target() to work properly:


function casetracker_set_target($node, $target, $value) {

  if (!isset($node->nid)) {
    node_save($node);
  }

  $node->casetracker->$target = $value;
}

Title and body fields are coming through fine, but anything Casetracker-related isn't being saved. First off, the node_save is there because the casetracker property/object wasn't appearing in the node object until it was saved the first time through. I imagine there's a better way to do this, but that part at least appears to work.

It turns out that the node, with properly populated Casetracker fields, is being built, but then the Casetracker stuff appears to be discarded. I believe this is because the view is generating human-readable names, whereas the Casetracker fields require numeric ids.

Alex_b has indicated that he'd prefer to have feed mappers reside with their related projects. So perhaps this issue should be moved over to the Casetracker queue. I think y'all are part of the DevSeed family, right?

Anyway, I need some guidance. If it's a matter of getting the Views source to expose numeric ids, at least I'll know to concentrate my efforts there. Otherwise, I'm a little lost as to where to go from here.

Regards, C

P.S. No patch, no tests, no documentation, at this point.

ergonlogic’s picture

Hello again,

So, it turns out everything is fine with the code above, and Casetracker was just expecting numeric IDs, as I'd suspected. Switching the source Views (using XML Datasource) Field Output to "Raw", output the proper numeric IDs, and then changing the feed XPath parser fields to use the machine names (case_status_id, assign_to, pid, &c.) allowed the feed to properly import cases.

The pid doesn't mean anything though, in this context. I suppose the right thing to do here is to look at $content_type, so as to be able to map projects as well as cases. In my use case, I suspect that I'll end up attaching the feed importer to a project, so that the feed pulls in cases, rather than creating projects via the feed. However, I suspect a general mapper should support both. From what I can tell though, a project doesn't include any Casetracker data itself. As a result, a feed for projects would then just require title and body (and maybe others), but no Casetracker fields to target.

Anyway, I'll test a bit more, and post a patch.

Regards, C

clemens.tolboom’s picture

XRef #521752: Add FeedAPI Mapper support (Case Tracker project)

ergonlogic’s picture

Project: Feeds » Case Tracker
Assigned: Unassigned » ergonlogic

I'm taking this back up, as we now have a client sponsoring development.

Also, I'm moving this to the Case Tracker queue, since:

preferable location for a mapper integration is the module that is home to the mapping target.

-- The developer's guide to Feeds

ergonlogic’s picture

I've made some progress on this, which can be seen in my dev sandbox: http://drupal.org/sandbox/ergonlogic/1273096. It basically works as is, at least for importing cases, but needs some more work to be more complete, and a general cleanup.

I'm considering releasing this as a contrib module, rather than seeking to get it included in casetracker, since CT appears minimally maintained, and I've added a number of dependencies.

Progress so far:
* added default views based on views_xml (in the views_datasource project)
* added default feeds importer based on feeds_xpathparser
* implemented mapper for case-specific fields
* automatically add new case states on import

To do:
* config UUID in code & make cases unique based on UUID in feed
* generalize the content_type in casetracker_feeds_node_processor_targets_alter() to lookup the node types that are acting as cases (& projects)
* implement mapper for projects

ergonlogic’s picture

ryan.gibson’s picture

FileSize
1.28 KB

For those who just need the mappings and not the full module, here's a patch to add that file. This is just using the code that ergonlogic provided, so credit goes there.

In my case, I'm importing with JSON to the mapped fields.