Details
-
Bug
-
Status: Closed
-
Resolution: Fixed
-
7.0.X, 7.1.X, 7.2.X, Master
-
7.3.x, 7.2.x, 7.1.x
-
Committed
-
3
Description
Steps to Reproduce:
- In a 6.1 portal create a Calendar Event
- Open the created Calendar Event (just click on its link, do not edit it) and subscribe to its comments
- Execute the following query and save the classNameId returned that will be used for future queries:
select classNameId from ClassName_ where value like 'com.liferay.portlet.calendar.model.CalEvent'
- Ensure, with the following query, that there are records in the table:
select * from Subscription where classNameId in (select classNameId from ClassName_ where value like 'com.liferay.portlet.calendar.model.CalEvent');
- Upgrade to 6.2
- Ensure, with the following query, that there are records in the table:
select * from Subscription where classNameId in (select classNameId from ClassName_ where value like 'com.liferay.portlet.calendar.model.CalEvent');
- Upgrade to master.
- Check if there are still old CalEvent classNameId records in Subscription with the following query:
select * from Subscription where classNameId = <classNameId>
For the <classNameId> use the one returned in step 4.
Expected Results:
No records with old CalEvent classNameId should remain in Subscription table.
Actual Results:
Records with old CalEvent classNameId remain in Subscription table.
Attachments
Issue Links
- is related to
-
LPS-112455 CalEvent classNameId entries remain in AssetEntry table
- Closed
- relates
-
LPS-130963 CalEvent classNameId entries remain in MBMessage and MBDiscussion tables
- Closed
-
LPS-135622 CalEvent classNameId entries remain in ExpandoTable
- Closed