All of those links below the Search Box, with a small triangle (Carot) to the left are folders.
Any links with a hyphen [ - ] to the left are Content References (CREF for short).
Clicking on a CREF usually results in launching a component.
Users typically navigate to a particular CREF by clicking on a series of folders in a hierarchy until they find it, then launch a component.
Sometimes a customer wants the CREF to be located/re-located to a different folder hierarchy.
This is where the aforementioned mantra comes in handy, as well as knowing who to go to in order to move the CREF to a new folder hierarchy or new sequence in the current folder.
Portal administration is typically performed by somebody designated as the "Portal Administrator". The Portal Administrator will use Portal Administration tools to re-locate the CREF to its new location correctly, even if you say you want it moved to a new menu.
The Portal Administrator's work will essentially update the Portal Registry.
Components (CREF) initially get registered by developers/programmers in a development database. That is to say they (the components, not the programmers) are placed in a folder hierarchy when the programmer registers the component in the portal registry, using the Portal Registry Wizard.
If you ask a Programmer to move a component to a new menu, there is a high probability that he/she will interpret your request in a very different manner from the Portal Administrator, which will have some very unfortunate downstream consequences including Portal Registry corruption as well as Permission List corruption.
This is because unlike Portal Navigation, which only has one menu, the application development environment has hundreds of menus.
The first time the component was registered in the Portal Registry using the Portal Registry Wizard, its original application development environment menu relationship not only was recorded as part of the Portal Registry, it was recorded as part of Permission List configuration.
If a programmer removes the component from its original menu and adds it to a different menu, the original permission list will still be pointing at the old component/menu relationship. The original Portal Registry will still be pointing at the old component/menu relationship.
Running the Portal Security Synch (PORTAL_CSS) program, with "Delete invalid security" selected will remove the permissions associated with the old menu/component relationship from PSAUTHITEM. The Permission List will still be there. It just won't have the component/page permissions pointing to the old menu/component combination that no longer exists.
If nobody took the time to re-register the component at its new menu location (the application development environment menu object), or go on-line to the original permission list definition and authorize access to the component with its new menu object relationship, then testing will be disrupted, since the required permissions (authorizations) don't yet exist.
The best way to avoid getting bogged down in the first place is never to say "Menu" when you really mean "Folder". If you want to get a CREF moved to another folder hierarchy in the Portal Navigation Menu, you need to request that the CREF be moved to a new Folder.
