It's all about the answers!

Ask a question

Individual Artifacts not Automatically Generated in Base Artifacts folder?

Mary Miller (87232) | asked Dec 06 '19, 12:55 p.m.
edited Dec 06 '19, 12:57 p.m.
Good day,

I know when I create a Module that all of the individual artifacts are placed in the Base Artifacts folder or a subfolder of Base Artifacts.

However, when I create or import a requirement that is just part of the folder, it does not get a "copy" in the Base Artifacts folder nor a subfolder of Base Artifacts.

Why is this?  It could be related to this article:

I was expecting consistency in operations; however, I recognize there may be a reasoning behind why individual requirements are treated differently fromrequirements gathered into a Module.



Accepted answer

permanent link
Carol Watson (71017) | answered Dec 06 '19, 1:08 p.m.

 Hi Mary,

Only artifacts that are added to the Module will be added to the 'base artifacts' folder for that Module.  If you add non-module artifacts to the same folder in which the Module resides (which is what I think you're saying), they won't also be reflected in base artifacts unless you use "insert existing artifact" and add them to the Module.

And you're correct, base artifacts only come into play with modules.  If you use non-module artifacts too, those are handled differently.  For example, if you delete a non-module artifact, it's permanently deleted.  If you "remove" an artifact from a Module, and do not also check the box to permanently delete it, then the base artifact will still be in the base artifacts folder.

I recently had a situation where someone inadvertently deleted a base artifacts folder. While it didn't impact the associated module, since the artifacts were still in the database, there wasn't an easy way to "recreate" the base artifacts folder.  I did find there's a utility you can use with the support team, but in my instance the module was tiny so it wasn't worth the effort.  I cycled through and removed the Delete Folder permission for all Roles in all projects afterwards, to ensure that didn't happen again.

Hope this helps,

Mary Miller selected this answer as the correct answer

3 other answers

permanent link
Carol Watson (71017) | answered Dec 06 '19, 2:44 p.m.

 Hi Mary,

I should've said this at the start, there's really only ONE artifact and you're "displaying" it in the Module.  When you create a new artifact while in the Module, it stores that 'artifact' in the base artifacts folder it created.  If you "insert existing artifact" from any folder other than the base artifacts folder, you're still only displaying that artifact in your module, and it's still stored in whatever folder it was in to start with.  It's not going to add or move that existing artifact to the base artifacts folder.

Sometimes a better way to think of Modules is that they are a 'display of artifacts in hierarchical order'. 

On the Comments question, does your display look like the below screen shot?  If yes, it's not showing you a Comment, it's only showing the artifact to which the Comment will be added should you add one.  That's what is meant by (0) and why you don't see it in Recent Comments on the Dashboard.  Once you actually add a comment to that artifact it will show (1) in the sidebar, as well as the actual Comment.

Does that help? You didn't mention, but I believe you've said in the past that you were on 6.0.6, is that correct?


Mary Miller commented Dec 06 '19, 2:51 p.m. | edited Dec 06 '19, 2:54 p.m.
Okay, this all makes sense now.  I am making sure that I gather as much information as possible on how Base Artifacts work and any pitfalls.  I am also gathering as much information as possible to evaluate the pros and cons of developing requirements that are only in a folder vs. a Module structure.  I am more used to using Modules and not worrying about Base Artifacts.

I took a closer look regarding my question on comments.  I see the same behavior with existing requirements and newly created requirements.  I must need a vacation!

Thank you, all of this helps!



permanent link
Mary Miller (87232) | answered Dec 06 '19, 2:09 p.m.

This does help.  I have 2 more questions.  I created an artifact with the same folder (SRS Folder) as the Module.  We will call it requirement 135.  I then opened the Module and then inserted the existing requirement 135 into a Module. 

However, the requirement 135 artifact was not placed in the Base Artifact/SRS Folder, and it was not in the Base Folder either.  I am guessing a "copy" of requirement 135 should have been placed in a Base Artifact Folder or Base Artifact subfolder?  Maybe I misconstrued what you were saying. 

I also noticed that when I did "Insert an Existing Artifact", the Artifact Comments gets updated with requirement 135's unique ID and text with a (0). 

However, if I go to the Comments widget on the Project Dashboard, I don't see requirement 135.

Is there a rationale for that happening or is it one of those things where the tool just works that way?

Thanks again!


Carol Watson commented Dec 06 '19, 3:22 p.m.

Last comment for you - there's new feature in 6.0.6 lets you designate a folder for Base Artifacts.  I've been using it for new Projects and name the folder Z: Base Artifacts so it ends up at the bottom of the Folder list and out of the way.  It's not perfect because it recreates the folder structure of the Module (see the below screen shot) for some reason, but it does give you a means to move them to the bottom where they are less noticeable.


permanent link
Davyd Norris (2.4k217) | answered Dec 06 '19, 7:25 p.m.
I find people get really wrapped around the axle over the whole 'base' artefact thing, especially if they have come from a DOORS Classic background.

The simple fact is that the artefacts you see in the folders are the actual requirements - they are not copies of the things you see in Modules, they ARE the things in the Modules. This is completely different to DOORS Classic where the requirements objects are created and live inside one and only one Module.

In DOORS Next Gen, a Module is is really just a 'Collection with a Context' - it's a holder for the requirements artefacts that you see in the folders, and it remembers the order and hierarchy in which you put them. You can even add the same requirement artefact multiple times into the same Module and it'll remember you put it in there each time.

The Base artefact folder concept was added to DOORS Next for those people who came from DOORS Classic and didn't get how Modules have changed and, IMHO, it's made it more difficult for people to understand. Basically when you add a requirement to a Module in DOORS Next, what is actually happening is:
 - the requirement artefact is created in the repository and is put into a folder
 - the artefact is then inserted into the Module in the place where you indicated

If you get your team to alter their mindset to think of the requirements artefacts being stand alone objects that live in the repository as a whole, organised by folders, and that they may also be inserted into and arranged in one or more Modules, then the whole idea of Modules gets simpler.

Modules then become the way you organise your requirements if you want something that looks like a document. If you only need a list or spreadsheet view of them, you can just use the folder hierarchy, or a normal Collection - Modules are overkill and actually harder to use if you just need a list you can query and sort.

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.