From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: Logged in as author Created File Storgae Item. Upload a pdf file into the CMS. Went to preview page. Clicked View in Browser. Expected to get Open or Save to Disk message for pdf file. But instead I got a 404 Not Found error. Version-Release number of selected component (if applicable): APLAWS+ WS3 How reproducible: Always Steps to Reproduce: 1. Enter url 2. Click View in Browser 3. Actual Results: 404 Expected Results: Open or Save to Disk dialog box. Additional info:
Two problems: 1) out-of-the-box xsl for FileStorageItem was missing the ccm dispatcher prefix (not an issue for production aplaws, but checked in a fix to the aplaws-ws3 branch @39353) 2) cms-item-adapters was missing a custom rule for FileStorageItem for 2) I've added FileStorageItem to aplaws-cms-item-adapters.xml for an aplaws-specific fix. A more involved fix will be needed for rickshaw final -- the basic problem is cms-item-adapters is defined site-wide, specific packages which provide new content types or authoring steps don't have a way of altering item adapters or authoring kits. Dan's got some ideas for solving this, but I'm not sure exactly what's involved at this point.
Was "un-fixed" when we had to pull out type-specific code from cms-item-adapters. Current workaround is to load with cms-item-adapters, and then after loading, replace with the modified version after install. The problem is that due to a difference in order of initialization, CMS legacy initializers can refer to object types initialized in other packages upon server startup, but they cannot reference these types via the loader. Resolution of this problem is dependent upon being able to register item adapters on a per-package basis.
Its unfortunately even more complicated that than. As well as each content type registering item adapters, there are generic 'assets' such as related links, file attachments, dublin core, which can be added to any content type. WHen adding an asset such as this you need to augment the rules for every content type, not to mention augment the authoring kit.
None of our Camden site "File Storage" items are accessable. For example: http://youth.aplaws.org.uk/ccm/content/community-and-living/welfare- and-benefits/file-storage-items/where-to-go-in-camden-for-advice-on- welfare-rights.en This shows... where to go in camden for advice on welfare rights (PDF 35.8KB) View in browser | Save to disk ...which is correct. Then clicking on "View in browser" gives: http://youth.aplaws.org.uk/cms-service/stream/asset/?asset_id=19864 404 Not Found /cms-service/stream/asset/ was not found on this server. --------------------------------------------------------- Resin 2.1.7 (built Fri Feb 14 12:48:13 PST 2003) Or clicking on "Save to disk" gives: http://youth.aplaws.org.uk/cms-service/download/asset/?asset_id=19864 404 Not Found /cms-service/download/asset/ was not found on this server. ----------------------------------------------------------- Resin 2.1.7 (built Fri Feb 14 12:48:13 PST 2003) Getting this working is high priority for the Camden New Website project. As someone who doesn't have the background knowledge to interpret comments #1, #2 and #3, can I just double-check, redhat are working on a fix? - James
The problems discussed in comments 1, 2, and 3 have already been resolved. What you are now seeing is an XSL problem. The original fix also included an XSL fix for the default FileStorageItem.xsl. However, this fix had not been applied to the APLAWS version of the xsl file. I've just checked in a fix which adds "{$dispatcher-prefix}" to the cms-service URLs which should provide the correct link.
Removing security severity; this is not a security related issue.
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future. Moving to ON_QA.