#6541 Record import_id and audit log during imports

v1.0.1
closed
General
2015-08-20
2013-08-08
No

We should keep track of the original source in imported artifacts. The import_id field is just right for that. IIRC, tool configs may have an import_id too. Both would be useful so that we could run reports on how my tickets or trackers (for example) have been imported from elsewhere.

Also record each import in the project audit log.

Related

Tickets: #6624

Discussion

  • Dave Brondsema

    Dave Brondsema - 2013-08-09
    • Size: --> 2
     
  • Dave Brondsema

    Dave Brondsema - 2013-08-23
    • Milestone: forge-aug-23 --> forge-sep-06
     
  • Cory Johns - 2013-08-26
    • status: open --> in-progress
    • assigned_to: Cory Johns
     
  • Cory Johns - 2013-08-28
    • status: in-progress --> code-review
     
  • Cory Johns - 2013-08-28

    allura:cj/6541
    forge-classic:cj/6541
    googlecodewikiimporter:cj/6541
    tracwikiimporter:cj/6541
    merciless:cj/6541
    configtree:cj/6541

    The merciless branch is branched off of 0.3.x which was branched just prior to the 0.4.0 changes that broke backwards compatibility, since we haven't resolved that yet in Allura. Make sure when this is merged, that it is merged into the 0.3.x branch and that that is released and used for SF.

    You will also need to apply the configtree changes to your local production.ini. Specifically, the tickets.import_id_converter setting was renamed to just import_id_converter.

     
  • Dave Brondsema

    Dave Brondsema - 2013-08-30

    I've handled the ming (merciless) portion of this. Version 0.3.9 (and 0.4.1) have the changes.

     
  • Dave Brondsema

    Dave Brondsema - 2013-09-05
    • QA: Dave Brondsema
     
  • Dave Brondsema

    Dave Brondsema - 2013-09-05
    • status: code-review --> in-progress
     
  • Dave Brondsema

    Dave Brondsema - 2013-09-05

    FYI, I have rebased versions of all of these I can push.

    The docstring on ImportIdConverter needs to be updated.

    ImportIdConverter doesn't know what type of artifact it's converting. Does that need to be accounted for yet? Or wait until we have a non-ticket implementation, so we know how exactly it would work.

    ForgeTracker/forgetracker/tracker_main.py assumes ImportIdConverter.get().expand will return a dict, but it could return a string, which will then error. And when it's a dict, querying by import_id.foobar will be unindexed. There is an existing index on import_id for a simple string match. I think an easy win is to just query {"import_id": expand_result} it'll work with strings & dicts, and querying against a full dict value will use the index that's on import_id

    In the audit log, the URL value ends up being like /--forgeimporters.base.import_tool--/5228fa9cd8be3540e721915f//--forgeimporters.base.import_tool--/5228fa9cd8be3540e721915f/ That's not ideal, but not too big of a deal either. The URL is set up by the taskd runner (not sure why it's duplicated), so we'd have to override it

     
  • Cory Johns - 2013-09-06
    • status: in-progress --> code-review
     
  • Cory Johns - 2013-09-06

    The following have been force-pushed:
    allura:cj/6541
    forge-classic:cj/6541
    googlecodewikiimporter:cj/6541
    tracwikiimporter:cj/6541

     
  • Dave Brondsema

    Dave Brondsema - 2013-09-06
    • Milestone: forge-sep-06 --> forge-sep-20
     
  • Dave Brondsema

    Dave Brondsema - 2013-09-09
    • status: code-review --> closed
     

Log in to post a comment.