Ticket #13770 (new PLIP)

Opened 2 years ago

Last modified 2 years ago

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:1 Changed 2 years ago by timo

  • Type changed from Bug to PLIP

comment:2 Changed 2 years ago by timo

  • Description modified (diff)
  • Milestone changed from 4.x to 5.0

comment:3 Changed 2 years ago by timo

  • Description modified (diff)

comment:4 Changed 2 years ago by timo

  • Description modified (diff)

comment:5 Changed 2 years ago by timo

  • Description modified (diff)

comment:6 Changed 2 years ago by timo

  • Description modified (diff)

comment:7 Changed 2 years ago by davisagli

  • Description modified (diff)

Noted tools that have already been removed

comment:8 Changed 2 years ago by toutpt

  • Description modified (diff)

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:10 Changed 2 years ago by jaroel

  • Description modified (diff)

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)?

Note: See TracTickets for help on using tickets.