Vandelay item import support for some default copy values.

Code pushed to working => user/berick/lp1209291-vandelay-item-import-defaults

Rebased branch to master and force-pushed.

Merged to master. Thanks, Bill!

I know this is already merged, but I still have a few questions about it.

1) I am wondering, was there consideration of leveraging the auto-barcode trigger which already exists in the DB? That is, any barcode starting with '@@' is auto generated at the DB-layer. We would lose the ability to set a custom prefix, but I am wondering how important that is apart from making the barcode not collide, and '@@' barcodes can never collide by design.

2) Regarding barcode collision avoidance, I looked at the code diff, and did not notice anything addressing that (though it was mentioned in the design spec). Or is that already handled by an existing part of Vandelay?

If it is important to have custom prefixes, I would prefer to see us modify the '@@' trigger to allow for '@VAN@' (for example), where 'VAN' could be any characters A-Z.

I think this would all be fairly simple to retrofit, and would be a (small) win for general unity. What do you think, Bill?

Dan,

Some thought was given to that. The prefix part you mention is one reason it wasn't used in the end. Another is that the generated barcode would either change (acp trigger sees /^@\w*@/ and rewrites it with the acp.id value) or conflict (trigger is taught to ignore imported items, somehow, but the sequences overlap at the exact wrong spot) when the copy is vivicated on asset.copy. Once a barcode is assigned, barcode stability is important in case the extracted (but possibly not yet imported) items are being used elsewhere, possibly even externally. Think: ACQ.

That said, if we can come up with a further generalized version of the @@-auto mechanism, I do think it would be a win.

--miker