Cascading Rules for attributes temporary suppression into rule tree

[Fa_St]

I'm currently and intensively using cascade attributes rules to guide my people into new WtPart attributes population. But I've in my database a lot of legacy WtParts whose attributes do not fit anymore the rules we set for new ones. In this scenario it is not possible to modify any attributes of this legacy parts, no matter if you make it trough edit mask or by importing an excel file. Cascading rules will block it.

The only way I have to be able to make a modification of these legacy WtParts is a time-consuming workaround:

1) make a loto of printscreen or document in detail the tree of cascading rules (in my case, round 30 rules)

2) delete all rules that are blocking the validation of the edit form or of the excel file (in my case, almost all)

3) make the modification

4) re-insert newly all the rules copying them form the screenshot.

Not comfortable at all. 

I suggest to place a toggle button to manage a flag into the cascading rule tree in WtPart Type and Attributes management interface: Rules ON-OFF.

By toggling it we can easily deactivate rules, make editing of these legacy WTParts and then toggle them again ON.

A more advanced feature can be the toggle flag posed on each rule, shown by right clicking the mouse on the rule itself.

[JeffZemsky]

Is the use case for administrative updates of legacy data or is it for users who are revising / iterating these legacy parts?

Is there any additional characteristic to help separate this old data from the new? 

[Fa_St]

Hi, the proposal can work for both cases, it moves to the admistrator the choice if to make these updates by himself or not. 

Since I'm also the Admin, I normally operate this way:

- I collect a certain number of modifications and then I made it by myself in massive way(excel file)

But if I have this new function, I can toggle rules, ask the man who has the urgency of a modification and the toggle it again.

PS: the problem does not exits with attributes of the WtPart that are designated when they are not in involved in rules: if the "edit" of the WtPart is made "internally" by the association procedure during the check in, all works.

So, in may case, on legacy codes: people can normally iterate or revise a WtPart when a CAD modfiication appears, but they cannot change other attributes you need to manage with edit mask (e.g. make/buy attribute...) 

Unfortunately there is no way to separate old from new parts, since basic these recognition is made by the same attributes we have to control with the cascade rules. And I cannot divide them since they are driving our customized process to update also the ERP database.....

[olivierlp]

Hello,

We are archiving your idea as part of a general review. This action is based on the age of your idea and the total number of votes received, as per this announcement.

You can always post a new idea with all the details required in the form.

Thank you for your participation.