Is renaming IDs possible?

[plonka]

Hi,

if I make a mistake in an ID field (status, custom field, ...), is it possible to change it after work-items have been created or will I have invalid data in the work-items?

Thanks,
Christian

[NickEntin]

Hi Christian,

Polarion is friendly enough to accept "unknown" (unconfigured) values.
I.e. let's say you had an item with "customField:test" and you wanted to change it to "customField:tested".
(so far we're speaking about query/persistency, not about display name of the field value)

You can do following:
- go to the enumerations and change "test" -> "tested"
- if you do query "customField:tested" - nothing will be shown (as existing items won't be updated by the change)
- now you do query "customField:test" (you have to type it in the query line, as query builder can help you with configured enumeration values, which is not anymore the case) - should show you all the old items
- do bulk edit and change "test" -> "tested" for those found items.

Please note that with Status it principally works same way, but bulk edit will require additional workflow configuration (e.g. as soon as you changed id from "test" to "tested" in configuration, existing items will be "lost in workflow" - there will be no allowed transitions from "test" to anything). Therefore for status, I'd recommend to create a new status "tested" and temporarily allow transition "test -> tested", and afterwards delete "test" as known status.

Hope this helps

Best regards,
Nick

[plonka]

Hi Nick,

yes, that helps. Thank you.

For the Status, it would be nice however to have a 'back to Initial state' button for those lost in workflow.

Cheers,
Christian

[plonka]

Hi, one more thing. I tried it and ralised that

Code: Select all

    <panel description="Custom Fields">
        <field id="@allCustomFields"/>
    </panel>


now shows both (test and tested in your example). I now list all valid custom fields separately, so that's a work-around, but is there a way to remove the old one completely (without SVN, that is)?

[NickEntin]

that's actually still a custom field, therefore from traceability point of view it's still there, disregarding of configuration (you can still find by it, see in the history of changes, etc.)

I don't remember exactly, but probably if you set a field to empty value, it will be removed from definition...

Best regards,
Nick
P.S. I don't think we should offer "back to initial state" as this might produce linking or attribute inconsistency - i.e. if you created some linked items by workflow you can control, what should happen to sibling items or e.g. to other fields (for instance, see "resolvedOn" or resolution field) - it's better to keep "reinitialization" under control.

[plonka]

Ok, I see.

Thanks!