Worker Node // Different Groups // Different Fieldsettings

[Bryson Jones]

This brings up a good design point.

I’m not sure what the official strategy is but our company establishes documentation for a deployment so that all fields are unique across an enterprise.

For instance, if you wanted a field for “project name” and it was User21 and some other department wanted a field called Facility Zip Code and they wanted it to be User 21, we don’t allow that. We set up our fieldsets so that all data maps across all groups.

This means that our deployments have far higher field counts but there is never confusion moving data between groups, departments, shows, or facilities. User21 is project name. You can make another field, but there is no “other” 21.

The real reason for this is that once you leave the Worker Node which is db aware and move into other scripting mechanisms, the field ID never has a name, only a number. XML translations would be a nightmare if you had to read field labels, for instance and parse by that instead of USER ID.

This is only how NSA/HidefCowboy has done it. If there are other strategies, please weigh in. But these days we are integrating so many separate systems that this convention is critical.

bryson

bryson “at” northshoreautomation.com

northshoreautomation.com

[Rolf Howarth]

Probably the easiest way to do this is to standardise your user fields across all your production groups. If some fields are used in one group and some in another simply don’t show them when customing your details panel and view layouts if they’re not relevant.

Having said that, if a user field has different meanings in different production groups, the worker doesn’t care. If you set User 21 to “Done” in the worker it doesn’t matter that in Group 1 that field’s label is “Transcode Status” and in Group 2 it’s called “Customer Number”. The fact that the worker displays helpful labels is only a convenience when writing the scripts.

If the two groups have very different user field mappings then it may be easier not to enter any field set name at all in the worker and simply refer to it as “User 21”. You will have to consult your mapping spreadsheet when first developing your worker script, but writing the worker script is something you hopefully only have to do once (and is done by the administrator, rather than day to day users) and won’t affect the regular operation of the script.

[Leonid Nekrasov]

Thank you guys. This are very useful recommendations.

@Rolf: Maybe you should think about some kind of “Zen of CatDV”. 10 or 20 guiding principles that could be found in the manual. That would make it easier for every beginner to make a good setup and to use your product in a proper way. Advanced users would consult professionals anyway.

Regards
Leo