}ElementAttribute dimensisons not showing up in "Manual" package selection

Pulse Pulse Tips
1

Is there a setting somewhere for this? Some control objects show up in the list of dimensions, but }ElementAttributes seem to be conspicuously missing.

2

Hi @jpusztai,

Element Attributes are documented as part of the dimension. Pulse does not backup the cube per-se, but it documents the attributes (.dimx) and all the attribute values by element (.dmd)

Regards,

Erik

3

Thanks, Erik. So }ElementAttribute dimensions should show up in the list of manual objects during package creation, correct? What should we do if they don’t?

4

Hi @jputzai,
Sorry if my previous answer was incomplete. Just to clarify, Dimension attributes are documented together with the dimension that they belong to and not as separate objects. You won’t see }ElementAttributes control dimension objects as part of a migration package.

Regards,

Erik

5

Hi @jpusztai,

Just to add to Erik’s comment, when you migrate a dimension, }ElementAttribute cube will not show up in the list because Pulse uses instead a custom file .dimx file to migrate the attributes.

In the example below I picked the dimension CRM Version, when migrating you will CRM Version.dimd file:

image
image.png2252Ă—935 163 KB

1 Like
6

Hi Vincent,
what if there is a rule attached to an }ElementAttributes cube? I need primarily to migrate the rule - how this case should be handled?
BR
Petr

7

Found the answer - if a dimension is added, then all prerequisites are added as well, including the rux file. It would be nice to have a specific filter item to be able to filter rule as an object type beside cube.
BR
Petr

1 Like
8

It would also be nice to be able to migrate changes in the }ElementAttributes dimension without the associated attribute data. That is just migrate the addition or deletion of attributes. Currently attribute migration is “all or nothing” with dimension structure and attribute values. But often members of dimensions will be different between dev & prod and it would be helpful to be able to migrate just the attributes.

9

Exactly - if I could vote for features in packaging functionality, that would be one of the points:

  1. Migrate only attributes definitions without values
  2. Possibility to go back from step 3 (Review Changes) to step 2 (Selection) without losing list of manually selected objects
  3. Possibility to save unfinished package and load its definition to finalize - this would be handy for huge packages