Retaining Group and Category when exporting apps

[DrGadget]

Is it my imagination or did something change/break when exporting apps? I could have sworn that if I had a (NAB) app in a certain Category and certain Group(s), that it would put that app into the same category and group(s) on the target instance, provided they exist there. If the category doesn't exist on target, it ends up in the category specified in Portal Admin, Uncategorized in my case. The category thing still seems to carry forward but the group thing doesn't and I swear it used to. Several times I have noticed I export and app and the group it's in in Source exists on Target but it always ends up in the default group for new apps on Target it seems. Then I thought maybe it was because the GRPID was different for the same group between the 2 instances, but the same thing happens whether the VVGRPID is the same. Which actually brings up an interesting question: if VVGRPID (and CCVATID for that matter) are different in other instances, and they likely are as they are basically just a next-number key, does it use the group name to see if it exists in the target instance? Can you enlighten us on exactly how app attributes (like Category and Group(s)) are carried forward from source to target instance when an app is exported?


And while on the whole topic of exporting stuff from one instance to another....

A lot of shops, certainly ours, have a traditional DEV->QA->PRD type set up. We have a training environment too, which is supposed to be a mirror image of production for users to mess around in. I'm finding myself going from instance to instance recreating groups and cats and pushing apps around, desperately trying to keep things in sync. There's gotta be an easier way. Totally shooting from the hip and mostly intended as a conversation starter there, but how about....

* the ability to push non-NAB apps around
* initiate app export from Portal-Admin-apps. Not sure why that's a NAB thing. To me it's an APP thing not a NAB thing.
* If category doesn't exist in target, create it (Add checkbox to control that behavior)
* if group(s) don't exist on target, create them. (Add checkbox to control that behavior )
* Export groups and categories, anyone?

[robert.swanson]

There haven't been any changes to the way categories and groups are imported.

For categories it attempts to match them up by name, deferring to the default category whenever a match cannot be found.

It turns out we've never accommodated groups on an import -- it always assigns the default group on the initial import of an app, then leaves the app's group membership alone on subsequent imports of that app. We'll look into better supporting the import of the app's group membership in 6.1.

We'll discuss the other items in your post and get back to you.

[DrGadget]

Interesting.

It makes sense that upon re-import you don't mess with the groups. I could have fiddled with app access on the target (PRD) and I wouldn't want some update to the App to mess with the Groups as that controls who can get to the app

Does it leave the category alone too upon reimport? By the same token I guess I wouldn't want that to change either if the app already exists and is in a different category on target (not blank).


I'll noodle on this some more. I've got some other ideas. I'll try to articulate them and send them along. The goal is to minimize admin type work to get apps, groups and cats into the various instances, and keep the various instances somewhat in sync, yet still allow for local overrides when needed...

thanks Rob

[robert.swanson]

It currently attempts to update the app's category on every import, though I think it'd probably make the most sense for both the category AND the group membership to only be set on the initial import of the app, wherever a matching category/group name can be found.

That way a subsequent re-import of the same app wouldn't suddenly cause its category/group membership to change in Production, which might not be desirable.

[robert.swanson]

FYI, the Valence 6.1 release that was just pushed out over the weekend includes this new import logic.