Bug 113469 - File Storage Item preview link gives 404 error
File Storage Item preview link gives 404 error
Product: Red Hat Enterprise CMS
Classification: Retired
Component: APLAWS-usability (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Scott Seago
Daniel Berrange
Depends On:
  Show dependency treegraph
Reported: 2004-01-14 05:47 EST by James Kearns
Modified: 2008-10-06 09:15 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-06 09:15:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Kearns 2004-01-14 05:47:53 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Description of problem:
Logged in as author@example.com
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):

How reproducible:

Steps to Reproduce:
1. Enter url
2. Click View in Browser

Actual Results:  404

Expected Results:  Open or Save to Disk dialog box.

Additional info:
Comment 1 Scott Seago 2004-01-14 13:00:10 EST
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.
Comment 2 Scott Seago 2004-01-21 22:01:07 EST
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.
Comment 3 Daniel Berrange 2004-01-22 05:03:37 EST
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.
Comment 4 James Kearns 2004-02-11 10:25:17 EST
None of our Camden site "File Storage" items are accessable.

For example:

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:
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:
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 
Comment 5 Scott Seago 2004-02-11 11:10:29 EST
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.
Comment 6 Josh Bressers 2004-06-18 13:22:25 EDT
Removing security severity; this is not a security related issue.
Comment 7 David Lawrence 2006-07-17 23:24:11 EDT
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future.
Moving to ON_QA.

Note You need to log in before you can comment on or make changes to this bug.