How to change the language dependency of an Attribute

Hi Jordan,

Can you elaborate a bit more what you would like to do? I don't quite understand it :)

Best,

Veronika

Hi Veronika,

I would like to get this attribute to be non language dependent. I understood that it is possible to do that with a script, but I don't know which functions to use.

Hope its clearer for you.

Hello Jordan,

it is not possible to change an attribute type once it has been created.

In your case it would mean, that all objects using the attribute type would lose the translations in all but one languages. And which one should that be? Data in your database backups would become invalid! For the same reason you cannot change the base type of an attribute from Number to Multi-line, boolean or any other base type.

Once an attribute type is in existence you cannot change it. You can only define a new, different attribute type and devise a strategy to migrate your data from the old to the new attribute type. A script would be useful for that and you will have to change your method filter and possibly portal configuration to show the new attribute type instead of the old one.

Also don't delete the old attribute type, because you would render all data in your backups that are stored in that attribute type inaccessible. You might rename it to something like "My old attribute (legacy)" so you recognize it, when you see it and don't get confused, if the new type is supposed to bear the same name as the old one.

And most certainly you cannot change standard attribute types just like you cannot change custom ones.

EDIT: If you ever decide to delete an attribute type, make a backup of a method filter containing that attribute type. That is the only way to bring the attribute type back into existence if you ever discover you need to access old data from a backup containing that attribute type.

Hi M. Zschuckelt,

Thank you for you detailed answer.

Are you sure that even with a script, I can't change the language dependency of an Attribute ?

Yes, quite positive! It would not make sense for the reasons I elaborated above. An attribute type essentially is an identifier (identified by a GUID) for a semantic property. You can rename it in all method languages, if you like, in order to adapt it to your terminology, but the basic properties are immutable:

• data type (number, text, datetime, value range...)
• language dependency
• the idea of its purpose (only defined in the users' context)

The attribute type is only an identifier for the set of these properties.

Consider the damage it would cause to your existing data, if you changed any of these. Just the same you cannot change the type of an object or a connection. Your existing data would not make sense any more, because it would not satisfy the (new) method!

If you need a different data type or type of language dependency it is fair enough to say that this is a different type of attribute and you will create a new identifier (GUID) for that new purpose. All your legacy data will remain interpretable with the old method. If there is a mapping from the old attribute type to the new attribute type, you can program that in a script (e.g. copy all Hebrew or Arabic values of the old attribute to the new language-independent attribute).

Also consider this scenario, which might happen to you any time: You merge with another organisation who also used ARIS and now you want to put your data together. You can be sure the standard method elements are the same in the other organisation - though the interpretation or purpose of usage for certain standard attributes may differ in some details. But you can be sure, that the other organisation's data can be imported to your environment, because any attribute that is a multi-line text in their environment is a multi-line text in your environment, too, and any attributes maintained in multiple languages in their environment also can be stored in your environment. Any custom attributes they defined do not exist in your environment and hence cannot overwrite anything here, while the specifics of your method are unknown in the other organisation and thus are safe from being touched.

You can import their method to your environment without conflicts and work with both methods in the same environment until your integration project has sorted out how to reach the synthesis of the methods.

Last and least, not being able to change the attributes of the standard method also ensures that you can import the demo database "United Motors Group" and investigate that.

Thank you for your detailed answers !