Bug 101113 - Use context list only shows 'public' when adding content type template
Use context list only shows 'public' when adding content type template
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: ccm-bugs-list
Jon Orris
:
Depends On:
Blocks: 100952
  Show dependency treegraph
 
Reported: 2003-07-29 05:56 EDT by Daniel Berrange
Modified: 2007-04-18 12:56 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-04 16:55:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2003-07-29 05:56:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.9 (X11; Linux i686; U;) Gecko/20030314

Description of problem:
The drop down select box for the 'use context' when adding a JSP template to a
content type only contains one entry - 'Public', while the
'cms_template_use_contexts' table contains three entries 'Public', 'Alternate' &
'Summary'. This turned out to be a case of someone hard coding the entries in
the select box, which we fixed in 5.2, so we can probably just merge p4 29962.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Go to content section
2. Go to content types tab
3. Select 'add template' link
    

Actual Results:  The use context drop down on the create template form contains
'Public'

Expected Results:  The use context drop down on the create template form
contains all contexts present in the DB.


Additional info:
Comment 1 Richard Li 2003-07-29 09:08:14 EDT
Scott, is there a good reason that we did this? (I assume there isn't, but I
want to double-check before merging.)
Comment 2 Scott Seago 2003-07-29 09:30:15 EDT
Richard, what do you mean by 'did this'? I think the only issue here is that a
pre-existing bug (or missing feature depending on how you look at it) was fixed
on the london 5.2 tree, and the fix has not been pulled across. If you mean why
didn't we merge this fix with the other use context fixes, my emphasis for FTVI
was more on the API and underlying functionalitry, and at the time this seemed
to be an unrelated UI deficiency. In any case, yes, we whould merge this.

In addition, once we merge this, we need to make a corresponding fix in the
item-template assignment UI (and possibly in the category-template assignment
too). Since originally all section-template mappings were 'public', the query
that pulls out the valid section templates to assign to a specific item (or
category) filters on the 'public' use context -- so if you assign a template as
'alternate' at the section level, you won't be able to assign this template to
an item explicitly. For the item(or category)-template mapping UI, we need to
either _not_ filter on use contexts (so that any template uploaded to a section
for a content type can be assigned to any use context for a specific item) or we
need to filter on the particular use context we're interested in (so when you go
to specify a specific item template for the 'alternate' context, you can only
chose from among those templates which are assigned as 'alternate' templates at
the section level). The choice of which of these to handle (or to handle both
via a more complex means) should be driven by the specific use cases envisioned.

For example, if your template contexts are for completely different types of UI
-- i.e. default, printer-friendly, text-only, WAP, etc., then there's no reason
a single template will ever be used for more than one use context, and we should
apply the filters. If the use contexts are more audience-based or use some other
distinction where it's possible that a single template could be used for public
use contexts in one case and alternate contexts in another, then we should not
apply this filter.
Comment 3 Richard Li 2003-07-29 15:28:20 EDT
29962 merged @34077
Comment 4 Daniel Berrange 2003-08-01 10:41:43 EDT
Done in p4 34077
Comment 5 Richard Li 2003-09-04 16:55:41 EDT
Resolved in Troika. Scott's comments merged into pending queue for docs.

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