Description of problem: When a ContentItem is created through the PageCreate class, the item is created and then the Bundle is created. In the constructor for ContentBundle, there is a call to addInstance. Inside of addInstance, it grabs all of the current instances to make sure that there is not currently an instance of that language. This check causes a database hit. However, before the database can be hit, the persistence layer has to flush the content item. Thus, the content item is saved and inside of the afterSave method, the parent is null so no context is set. Then, inside of the addInstance method the parent is set. Then, when the content item is saved again, the context still is not set because this time m_wasNew returns false. So, the context of the primary instance of the bundle is never set which means that the permissions are not correct. Specifically, this makes it impossible for a public user to view a published item and it makes the workflow open to pretty much anyone. the following patch is one way to fix this problem: [randyg@graebner intragroupe]$ diff -u cms/src/com/arsdigita/cms/ContentBundle.java intragroupe/src/com/arsdigita/cms/ContentBundle.java +++ intragroupe/src/com/arsdigita/cms/ContentBundle.java Wed Oct 22 16:04:16 2003 --- cms/src/com/arsdigita/cms/ContentBundle.java Wed Oct 22 15:59:10 2003 @@ -89,7 +89,6 @@ Assert.exists(primary, ContentItem.class); setDefaultLanguage(primary.getLanguage()); setContentType(primary.getContentType()); + primary.setParent(this); addInstance(primary); super.setName(primary.getName()); Version-Release number of selected component (if applicable): 6.0 How reproducible: Always Steps to Reproduce: 1. Create a content item and notice that it does not appear in object_context_map 2. 3. Actual results: the bundle should be the context Expected results: the object has no context Additional info:
I couldn't reproduce this bug on dev or 6.0.x. Looking at the code, the call to instance.setParent(this) in addInstance should always set the context.
I can no longer produce it either. When I originally filed the ticket, the call to hasInstance(instance.getLanguage()) within the addInstance method (it is in the Assert before the call to instance.setParent()) was causing the system to flush itself and the instance would save with no parent. However, it appears that in the current code the hasInstance call is able to determine if a DataAssocationCursor is empty without flushing objects to the database. So, I guess we can close out the ticket if it is indeed possible to execute the below code without flushing to the database. final DataAssociationCursor instances = instances(); instances.addEqualsFilter(ID, instance.getID()); return !instances.isEmpty();
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future. Moving to ON_QA.
Closing old tickets