Bug 103389 - getPublicVersion() does NOT return the latest public version
Summary: getPublicVersion() does NOT return the latest public version
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other
Version: 6.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Vadim Nasardinov
QA Contact: Jon Orris
URL:
Whiteboard:
Depends On:
Blocks: 100952
TreeView+ depends on / blocked
 
Reported: 2003-08-29 17:36 UTC by Mike Bonnet
Modified: 2007-04-18 16:57 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-12-10 02:03:41 UTC
Embargoed:


Attachments (Terms of Use)

Description Mike Bonnet 2003-08-29 17:36:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131

Description of problem:
The javadoc for ContentItem.getPublicVersion() states: Get the live version for
the item. If no live version exists, return the latest pending version, if any.

If no live version is found, getLiveVersion() just calls getPendingVersion(),
which calls getVersion(PENDING, m_pending).  This method retrieves all of the
pending versions (in database order) and returns the first one.  In Oracle, this
will generally be the earliest pending version.

This is contrary to the javadoc for the method.  This also breaks publishing
when multiple versions are present, since PublishLifecycleListener uses
draft.getPublicVersion() to retrieve the pending version (which it will update
to live).

This one case is a serious problem, but is indicative of the general brokenness
of our handling of multiple pending versions, and needs to be addressed.

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


How reproducible:
Always

Steps to Reproduce:
1. Create multiple pending versions of a ContentItem.
2. Call getLiveVersion().

    

Actual Results:  You will most likely not get the latest pending version.

Expected Results:  You should have gotten the most recently created live version.

Additional info:

I'm marking this high because it causes publishing to break in hard-to-trace
ways (associations will get updated to the latest pending version during copy,
but an old pending version will become the live version).

Comment 1 Vadim Nasardinov 2003-08-29 19:58:54 UTC
(14:45:37) ad Vadim: hey mike, are you there?
(15:13:16) aD mikeb: yeah, hi
(15:13:47) ad Vadim: let's see... I forgot what I was going to ask you
(15:14:09) ad Vadim: oh yeah, can you take a quick look at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103389
(15:14:54) aD mikeb: Yeah, what about it?
(15:15:17) ad Vadim: the test case for this is reproducible via UI only.
is that correct?
(15:15:30) ad Vadim: can we now create multiple pending versions through
the UI?
(15:15:43) aD mikeb: No, it's not reproducible through the UI.
(15:15:48) ad Vadim: ah, ok.
(15:16:02) aD mikeb: This problem manifested itself in a unit case written
by Starwood
(15:16:15) aD mikeb: unit test, that is
(15:16:29) ad Vadim: do you have a unit test that can be adapted to work
with an existing stock content type?
(15:17:12) aD mikeb: They were calling publish() multiple times without
calling unpublish(), creating multiple pending versions. This was causing
inconsistent behavior with associations.
(15:18:24) aD mikeb: I don't have anything simple that I can use now, but
you could probably write a simple one that creates 3 pending versions of
an item, and then calls getPublicVersion() on the draft.
(15:18:39) ad Vadim: ok, will do. thanks.
(15:18:43) aD mikeb: np


Comment 2 Vadim Nasardinov 2003-09-04 21:57:39 UTC
Fixed in the following changes
Change 35699 on 2003/09/04 by vadim@el-vadimo 'This fixes the test ERROR in co'
Change 35694 on 2003/09/04 by vadim@el-vadimo 'Inlined and remove the private '
Change 35693 on 2003/09/04 by vadim@el-vadimo 'Restored the caching of the pen'
Change 35692 on 2003/09/04 by vadim@el-vadimo 'Inlined the implementation of g'
Change 35690 on 2003/09/04 by vadim@el-vadimo 'This fixes testGetLiveItem10338'



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