If a user deleted a Content item (Test Case) from a Document (Test Suite) by mistake...How can I add that same Content item (with the same id) back into that Document?
I can export the Test Suite "as of" a previous date to see the removed content (Test Cases) and relationships. How can I add those Test Cases back into the document...then re-establish relationships?
We recently updated from 10.5 to 11.0...but have not yet enabled document/content versioning.
If we delete any content from document intentionally or non intentionally we can't create content on the same ID again because once i tried to delete a content but after deletion that id is not released by Integrity means it is still allocated. But if for ID creation there is some concept of DB or we can say there is some linkage with DATABASE then we can release it manually but as per my understanding it's not there just a blind guess.
And whenever we create a content it gives the next free ID in sequential order so for example if you delete a content of having ID 3 and ID 4,5 and 6 also exist in the system , so whenever you will create new content even after deletion of ID 3 it will allocate ID 7.
Hope this helps.
I know I cannot create a new content item with the same id. That is because the removed content item still exists in the PTC database with that id.
The Content->Delete menu just breaks the parental relationships to the content item (im removecontent)...rather than actually deleting it from the database (im deleteissue). You can still view the removed content item by entering the ID in the Item field in the GUI.
So the removed Test Case still exists with most all the data content..it is just no longer related to other items or associated to a parent. What I am looking to do is to re-establish the parental relationship broken by the Content->Delete (im removecontent).
I tried a few options in CLI (im movecontent, im insertsegment) but they all produced an error indicating the item was not associated to a parent.
I was able to do this to some degree using the CLI (im importcontent). The item id showed up when I viewed the Test Suite...but content was not displayed properly...and PTC still did not fully recognize it as content. The parental relationship was not properly re-established.
From a database perspective...I see no reason I should not be able to restore a parental relationship...broken by removing content. All the data is there...relationships just need to be re-established. PTC allows us to insert content from another document...why would it not allow us to insert orphaned content...previously removed from a document?
One option is copy the content from historic view (by using view as of function). The downside is this will create a new content in your document with a new ID.
Second option is, using im editissue --import to change relationship fields. It's like we re-add the content item to Contains field of document item, and re-add shared item to References field of node item. You know we cannot edit Contain/References fields directly, so CLI command with --import parameter is required. You can get original relationship field value from item history.
The second option can help to "actually" roll back. But it require administrator to run that command, and should be very careful with --import command!!
Ran into a similar issue - but I can't find the --import argument in the documentation. What's the syntax for this? If I just do 'im editissue --import 12345' - assuming 12345 is the item I want "back", it says 'Modifying item... Updated item 12345' and thats the end of it. I don't actually see record of anything being modified either.
Is there a long way around - so to speak - where I could update a table in the DB to "re-connect" them (or something equivalent?)
Firstly I don't think it's a good idea to change the database table directly.
It's possible to repaire the relationship via im editissue --import command but it's not PTC officially support (that's why --import option is not documented). So if user can accept to re-create a new content by copy from a historic document version, then please don't try --import, because if you import an incorrect value it will cause relationships a total mess.
I just give you an example here (you should test in your test env carefully):
After delete the content 2935, you will see:
in item 2935 history, you will see References changed from 2936xyz to empty
in item 1869 (document item) history Contains changed from 1935ay, 2935ay to 1935ay (2935ay is removed)
Then we can try the following command to add these back (like assign the fields orignal value before you delete the content):
im editissue --import --field=References=2936xyz 2935
im editissue --import --field=Contains="1935ay, 2935ay" 1869
Again it's not supported to use --import command in Integrity because it will override some rules and constraints. You shouldn't try this if there is other workaround like copy from document history version.
Sorry for the late reply,
In general I agree, I don't like having to override things or muck about in the database... but every now and then, there's an instance where someone does something bone-headed and for reasons that I can't predict, everything grinds to a halt and either a whole bunch of stuff has to run through a bureaucratic mess of signatures and re-submitting things into document controls and work stops while signatures are needed by half a dozen people.... point being, its a fringe case and *should* never happen... but it does once and a while, and an item truly needs to be restored or we suffer the consequences so to speak (and since time = money...)
Its not that we need to re-use an ID for something new, its that we need the whole item back with its original ID so that a trace report can be run (and not fudged in Excel) and a historical retrieval can be done without having to piece together Items with shared items, notations about what/why something has a modification/creation date after some report was run..
An undocumented and difficult to use method of restoring an item (in my opinion) is a good thing, as long as it actually exists. The difficulty being a good deterrent for people to not delete things less they get flogged 😉 Usually when I'm asked to delete something, my first response is (in a very Microsoft fashion), "Are you sure you want to delete that?" Then I usually remove relationships to anything that might show up in a report they'd run, and move said item/document into my "document graveyard" project for all the "just in case" scenarios... but I can't catch them all and restoring the DB to a previous point in time with almost a million items and people constantly using the system is no small feat - even if its restoring it to a sandboxed virtual machine (it shouldn't be *THAT* difficult).
Anyway, you get the idea/sentiment and I certainly get the possible reprocussions (which is why such an action would only be done by an admin and tested in staging/dev first). Thanks for the cander and reposne. I think a lot of this comes down to better training from my end so mistakes like this don't happen.
Have you got any idea to do the same because i also need the same. And if you any idea is to possible to share with me ? Waiting for your response John.