Bug 997571 - ISE when attempting to edit some cloned channel
ISE when attempting to edit some cloned channel
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Satellite Synchronization (Show other bugs)
560
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stephen Herr
Jan Hutař
:
Depends On:
Blocks: sat560-blockers
  Show dependency treegraph
 
Reported: 2013-08-15 11:51 EDT by Jan Hutař
Modified: 2013-10-01 17:59 EDT (History)
1 user (show)

See Also:
Fixed In Version: spacewalk-backend-2.0.3-8-sat
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-01 17:59:23 EDT
Type: Bug
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 Jan Hutař 2013-08-15 11:51:10 EDT
Description of problem:
When I want to manage some cloned channel, I'm getting ISE.


Version-Release number of selected component (if applicable):
spacewalk-java-2.0.2-15.el5sat


How reproducible:
always


Steps to Reproduce:
1. Check webUI Channels -> Manage Software Channels -> <some_channel>
   (I do not know how to create that "<some_channel>", it comes from
   some old dump and was OK before)


Actual results:
ISE and traceback in catalina.out


Expected results:
Form should be displayed
Comment 3 Tomas Lestach 2013-08-16 03:20:08 EDT
The reason for the ISE is that the imported channel does have filled the 'channel_access' field (private/protected/public). We rely on this field for custom channels.

Because there's DEFAULT defined on the rhnChannel table

    channel_access      VARCHAR2(10)
                            DEFAULT ('private'),

it looks like the satellite-sync code explicitly set null for this column.
Resetting to 'Satellite Synchronization' component.
Comment 4 Stephen Herr 2013-08-19 16:55:30 EDT
In reply to Tomas Lestach from comment #3)
> The reason for the ISE is that the imported channel does have filled the
> 'channel_access' field (private/protected/public). We rely on this field for
> custom channels.
> 
> Because there's DEFAULT defined on the rhnChannel table
> 
>     channel_access      VARCHAR2(10)
>                             DEFAULT ('private'),
> 
> it looks like the satellite-sync code explicitly set null for this column.
> Resetting to 'Satellite Synchronization' component.

It's less explicit and more just the way that satellite-sync treats all unspecified attributes, but otherwise this is exactly correct. I have added code to check for this so we do not break backwards-compatibility.

Committing to Spacewalk master:
99d63c92a987ce66a1a31b66bb993389921739da
Comment 8 Clifford Perry 2013-10-01 17:59:23 EDT
Satellite 5.6 has been released. This bug was tracked under the release.  

This bug was either VERIFIED or RELEASE_PENDING (re-verified prior shortly
before release). 

Moving to CLOSED CURRENT_RELEASE. 

Text from Upgrade Erratum follows:

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2013-1395.html

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