Sakai's Help system started off with a rigid assumption that a tool's ID would map directly to the name of an XML file that configured the tool's online help documentation.
Back in 2005, Sakai tools gained the ability to point to documentation that had a different name. This is implemented in the tool's registration file with the tool configuration attribute "help.id". For example, the "sakai.assignment.grades" tool is configured in "sakai.assignment.grades.xml" as:
description="For posting, submitting and grading assignment(s) online.">
<configuration name="help.id" value="sakai.assignment" type="final" />
When the CharonPortal builds links to help documentation for the tool, it checks that config property, and if it exists it overrides the tool ID when constructing the Help URL.
However, the logic in the Help module itself was never updated to match this new logic. When it assembles its table of contents (in "registerStaticContent"), it continues to assume an exact match of tool ID to help file name. As a result, when it tries to actually load those files, it fails – silently, unless you have debug-level logging turned on:
DEBUG HelpManagerImpl:1068 - Unable to load resource: /sakai_assignment_grades/help.xml
Everything that's responsible for finding help documentation in Sakai should use the same logic. So far this discrepency has been harmless in practice because every existing "help.id" does happen to match an existing tool ID somewhere. However, as tools continue to migrate and diverge, there's nothing to prevent a "help.id" that doesn't match a deployed tool's ID. HelpManagerImpl should be modified to take the "help.id" scheme into account.