We have plone/app/portlets/portlets/calendar.py and events.py, but these are only here for backwards compatibility. The real portlets are in plone.app.event now:
$ cat calendar.py
# avoid broken persistent object
from plone.app.event.portlets.portlet_calendar import Assignment
$ cat events.py
# avoid broken persistent object
from plone.app.event.portlets.portlet_events import Assignment
I think if you still have such a persistent object in your database and you run bin/zodbupdate, the script recognises that the class is at a different place now, and rewrites the object. I did not test it in this case, but that is what I expect. When going from Python 2 to 3 in 5.2, everyone will have run this script.
So when was this change done? In 2011, first in commit 6a2c8c6 and a small change in 9adde7d. Both commits are in plone.app.portlets version 2.5a1. This was included since Plone 4.3.4.
So I think we can safely remove these two files on master, which is for Plone 6 only.
Can someone confirm that my conclusion is correct?
We have
plone/app/portlets/portlets/calendar.pyandevents.py, but these are only here for backwards compatibility. The real portlets are inplone.app.eventnow:I think if you still have such a persistent object in your database and you run
bin/zodbupdate, the script recognises that the class is at a different place now, and rewrites the object. I did not test it in this case, but that is what I expect. When going from Python 2 to 3 in 5.2, everyone will have run this script.So when was this change done? In 2011, first in commit 6a2c8c6 and a small change in 9adde7d. Both commits are in
plone.app.portletsversion 2.5a1. This was included since Plone 4.3.4.So I think we can safely remove these two files on master, which is for Plone 6 only.
Can someone confirm that my conclusion is correct?