Greetings,
How can I cancel the option "Purge.." in a module?
Thank you!
Juanfergar - Fri Mar 24 05:52:02 EDT 2017
Re: Cancel the option Purge
Mike.Scharnow - Fri Mar 24 06:41:33 EDT 2017
By "cancel" you mean "prevent users from purging objects"?
I'm not sure whether this is possible easily, but in my opinion, you should tell your company not to do that.
Usually, the reason for companies wanting to disable purging of objects is that these objects are somehow "important" as they have been exposed e.g. to a report or to a 3rd party company. But: for these cases you have baselines, so every "important" report or export should be done from a baseline. And these baselines cannot be modified, there is no purging possible.Several companies state that they have to be able to be completely transparent about their history of objects to fulfill standards in aviation or automotive, but this is true only for objects in a fixed state. Consider e.g. source code: if a developer creates a new .c file and even before they do their first compile, they notice that they misspelled the file name, or they see that the new source should reside in an already existing file, so they delete the file again: should it, in this case, also not be possible to delete such an object?
One of the reasons not to disable purging is that DOORS may become very slow if there are lots of deleted unpurged objects. May be you have one module that is constantly updated by some other source, let's say an excel file. Users will perhaps delete all existing objects in a specific chapter and create them again from the excel file. In this case, the file gets bigger and bigger and finally you cannot work with it any more.
Re: Cancel the option Purge
PMiller - Fri Mar 24 18:46:19 EDT 2017
It would be useful if Juanfergar could describe why the "Purge" option needs to be removed? What is the problem that is being experienced with the "Purge" feature? There could be a simple solution if we have more information.
In addition to Mike Scharnow's correct points about modules becoming slow due to compounding unpurged objects and compliance to information retention regulations, a recommended best practice in DOORS which resolves these two points is to purge all deleted objects after a baseline has been saved. There is no value in keeping these in the next version as they have already been recorded in the previous baseline where they cannot be deliberately or inadvertently purged.
Paul Miller
Melbourne, Australia
Re: Cancel the option Purge
Juanfergar - Mon Mar 27 02:35:54 EDT 2017
We have two problems with this option:
1. If the object is linked with other object, the link is lost.
We use a column called Suspect Link, which shows the changes that have occurred in incoming links and outgoing links. The problem is that the script looks at the history of the linked objects. When you use the Purge option, the link disappears and therefore the linked object don't know anything about the other object.
2. The Purge option don't generate Histoy, so we can't know what happened.
When you use the Purge option, in the historial of the module this is what appears, so we can't know what has happened.
Unfortunately we are many people in the company, so we can't control everybody and sometimes they use this option.
Re: Cancel the option Purge
Mike.Scharnow - Mon Mar 27 05:15:05 EDT 2017
Juanfergar - Mon Mar 27 02:35:54 EDT 2017
We have two problems with this option:
1. If the object is linked with other object, the link is lost.
We use a column called Suspect Link, which shows the changes that have occurred in incoming links and outgoing links. The problem is that the script looks at the history of the linked objects. When you use the Purge option, the link disappears and therefore the linked object don't know anything about the other object.
2. The Purge option don't generate Histoy, so we can't know what happened.
When you use the Purge option, in the historial of the module this is what appears, so we can't know what has happened.
Unfortunately we are many people in the company, so we can't control everybody and sometimes they use this option.
Well, my opinion: (perhaps also someone else might want to give additional examples / opinions / arguments pro or contra):
1. Objects with In-Links can usually not be deleted. When objects with out-Links are deleted, the links are deleted as well, so the concept of suspect links does not apply. Lets have a look at the use case where this might occur. Say, you have a high level requirement and a low level req that links to the high level req (link direction: from low to high). Now, when the low level req, which is a refinement of the high level req, is deleted or purged, there should not be a need to adopt the high level req. Suspect links are more often needed for the the case where the high level req is modified and the editor of the low level req must be informed that the refinement may not be correct any more.
2. well, the user "Administrator" will still be able to read read-locked data. But independent from this, this is a case where the purged object is only important if it was inside a baseline previously. And in this case, you can create a baseline comparison script to find out which objects do not exist any more.
Re: Cancel the option Purge
Thosicus - Mon Jun 12 17:01:10 EDT 2017
Another option to consider is the formal.dxl file, which creates the menus in DOORS modules. A careful editing of this file, by commenting-out the lines having to do with purging, will remove the Purge tool from your module menus. This option is only practical if your users share a common DOORS application such as is used in thin-client (Citrix) configurations, or if their thick-client DOORS applications are installed via a Software install script that does other things beside install the executable.
And like Mike and Paul have said above, purging is sometimes a good thing. I would suggest keeping it active for the DB admins.
Good luck!