Ticket #13770 (new PLIP)
Removal of selected portal tools
Reported by: | timo | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 5.0 |
Component: | Unknown | Version: | |
Keywords: | Cc: |
Description (last modified by jaroel) (diff)
Proposer: Timo Stollenwerk
Seconder: Ramon Navarro Bosch
Abstract
Motivation
Refactor code out of CMF to use only zca
Assumptions
Proposal & Implementation
Remove deprecated tools.
If it's a used tool (like portal_url) we register a utility because getToolByName try first to return a utility. The main issue is with Python Script: the security will breaks but they should be removed.
You can register a computed attribute on Plone site and dexterity base content so context.portal_foo will works.
Deliverables
Short Term:
- portal_actionicons (deprecated)
- portal_interface (deprecated)
- portal_undo (deprecated)
- portal_url (deprecated)
Archetypes / ATContentTypes:
- portal_atct (move into ATContentTypes)
- portal_factory (move into ATContentTypes)
- portal_form_controller (move into ATContentTypes)
- portal_metadata (move into Archetypes)
Mid Term:
- MailHost (plone.app.registry PLIP)
- RAMCache (plone.app.caching)
- plone_utils (skins removal PLIP)
- portal_calendar (plone.app.event PLIP)
- portal_migration (move to @@upgrade browser views)
- portal_password_reset (plone.app.users PLIP)
- portal_properties (plone.app.registry PLIP)
- portal_registration (skins removal PLIP)
Long Term:
- portal_transform (factor out main functionality into a utility)
- portal_controlpanel (after plone.app.registry PLIP)
- portal_groupdata/portal_groups (complex plone.app.users PLIP)
- portal_memberdata (after plone.app.users PLIP)
- portal_membership (after plone.app.users PLIP)
Never / Hard:
- portal_catalog
- portal_actions
- CMFEditions
- portal_css
- portal_javascript
- portal_quickinstaller
No idea:
- portal_referencefactories
- portal_view_customizations (ask Andi Zeidler)
Risks
Participants
Timo Stollenwerk Ramon Navarro Bosch
Progress
These tools have already been removed:
- portal_actionicons
- portal_discussion
- portal_undo
- portal_interface
Change History
comment:7 Changed 2 years ago by davisagli
- Description modified (diff)
Noted tools that have already been removed
comment:9 Changed 2 years ago by alepisa
Portal interface can be considered remove after:
I would like some review/advices before screwing up things :D
comment:11 follow-up: ↓ 12 Changed 2 years ago by tom_gross
I once wrote some code to migrate portal_properties to plone.app.registry. I added it in https://github.com/plone/Products.CMFPlone/commit/32cea4b2e66bf32a7f33d53464f855ac9a7a7e11. You can use it if you want. I guess we have to make a decision how we want to remove portal_properties and probably other data providers. There are several options:
a) move the values to plone.app.registry and keep a backwards compatibility stub (this is more less what my code does)
b1) move everything to plone.app.registry for Plone core and remove the tool completely. Then we have to make sure the values of the registry are accessible from restricted code and templates and need to provide detailed documentation how to migrate properties to the registry for 3rd party developers.
b2) move everything to plone.app.registry for Plone core and remove the tool completely and provide a package (which is not part of Plone core like https://pypi.python.org/pypi/collective.searchform/1.0) providing a backwards compatibility stub to make it easier for 3rd party developers migrating their code.
comment:12 in reply to: ↑ 11 Changed 2 years ago by timo
Replying to tom_gross:
I once wrote some code to migrate portal_properties to plone.app.registry.
There is already an implemented PLIP for that (with a migration step): https://dev.plone.org/ticket/10359. There is still work to do, but it is basically done. This PLIP is somehow a follow up of the #10359 PLIP.
comment:13 Changed 2 years ago by seanupton
If portal_memberdata goes away in Plone 5, what might be a reasonable way to get some set of property keys for users -- site.portal_memberdata.propertyIds() -- generally? Per-user in PAS this is no problem, but it seems like doing this generally may be tricky without maybe moving the property sheet to a PAS plugin?
Since PlonePAS depends on using portal_memberdata now to get property schema (for mutable_properties plugin), it seems sensible perhaps in moving the property sheet(s) onto Products.PlonePAS.plugins.property.ZODBMutablePropertyProvider -- but does this cause problems for other PAS plugins providing properties (e.g. read-only LDAP)?