Folders question

[erics]

Hi There,
I've inherited a mid-sized Cognos system with a good number of reports already created.
My boss recently asked me to put all new report into the root of public folders, but when I do that, the report never shows up, and I'm the admin.
So, what I'm wondering is, what do I need to know about these folders? What's the difference between a package and a folder? And do things need to be in there?
And what kind of hierarchy to you guys use in order to hide dev/deprecated versions of reports from clients?

Eric

[Lynn]

Hi There,
I've inherited a mid-sized Cognos system with a good number of reports already created.
My boss recently asked me to put all new report into the root of public folders, but when I do that, the report never shows up, and I'm the admin.
So, what I'm wondering is, what do I need to know about these folders? What's the difference between a package and a folder? And do things need to be in there?
And what kind of hierarchy to you guys use in order to hide dev/deprecated versions of reports from clients?

Eric

You will find that administering a Cognos environment is best done once you've had some training. The Cognos Connection user guide should address some of the questions you are asking, at least with regards to the difference between package folders and regular folders. But you really should request some formal training following the administrator learning path if you intend to administer the system.

I could give a simplified answer that regular folders are used to organize entries and that package folders reflect data that is available for reporting, but I don't know if that really does justice to the topic. You don't need to have anything in either type of folder but an empty regular folder begs the question as to why not just delete it. You will always need a package folder if it is to be used for reporting.

Whether anything lives inside it is a matter of preference. This, and the other part of your question, is more about best practices. I tend to not put things inside package folders mainly because deployment is done by folder and not individual items within a folder. Separating the packages and the reports gives me more deployment control.

Ideally you'd have a dev and/or QA environment from which development content gets deployed to production. Users would only have access to production so there isn't any need to hide work in progress because it just won't exist in their environment. If you must have it on the same server you'd most likely create a separate folder for the development work and set permissions on it so that only developers can see and access that folder.

[bdbits]

To add to Lynn's great answer, I would definitely not put reports into the root itself. At least put them into a single folder, which can of course be in the root. You'll thank me later.  :D  There are a few things that must reside inside a package folder, mostly related to package-level drill-through definitions (which most people do not use). Otherwise I am with Lynn and would avoid putting anything inside a package folder. It definitely complicates deployments.

I really don't like doing dev and prod on the same box. An alternative to using folders and permissions would be to install multiple Cognos instances on the same box, but whoever has to manage installs and upgrades probably would not want the administrative hassle this entails. Probably folder permissions are going to be your best bet. I would just create root-level folders for "Dev" and if needed "Test" and restrict permissions right at that level.