Ticket #10344 (closed PLIP: wontfix)

Opened 6 years ago

Last modified 5 years ago

PLIP: update links and references on copy

Reported by: matthal Owned by:
Priority: minor Milestone: 4.x
Component: Archetypes Version:
Keywords: Cc: matt@…,Danny.Bloemendaal@…

Description (last modified by limi) (diff)

Proposer: Matt Halstead
Seconder: Danny Bloemendaal

Motivation

Copying and pasting a folder or folderish-type content currently results in UID based links in text fields (e.g. generated by kupu/tinymce) and references (via reference fields) which reference content in the copy tree not being updated to point to the new copies of these items in the destination tree.

e.g.

if we have the structure:

/a/b

where a references b either in text field links or reference field, then a copy of a will result in

/a/b /copy_of_a/b

where copy_of_a still links to /a/b instead of /copy_of_a/b

Assumptions

We assume that:

1) the methods for linking to other documents within text fields are either

  • site root relative paths
  • object relative paths
  • resolveuid style paths generated by kupu or tinyMCE

2) archetype reference fields are the only other forms of referencing another object

This proposal is only relevant to archetype based content with the above assumptions.

Proposal & Implementation

The proposal is to catch copy/paste events and update all text fields and reference fields where a reference points to an object within the copy tree. The copy tree is the object being copied and all decedents of the object's database path.

Additionally, it appears that all references in at least the reference field 'relatedItems' are lost when copying and pasting an object, so it would be useful to preserve these also.

Deliverables

  • egg package
  • doctests
  • plone 3 and 4 compatibility

Risks

We make specific assumptions about how references to other objects are stored and do not account for other methods.

Participants

Matt Halstead (matthal)

Progress

This proposal has been implemented and is currently being used in production. The package is called collective.updatelinksoncopy - see the  http://plone.org/products/collective.updatelinksoncopy/ for more details.

Change History

comment:1 Changed 6 years ago by vangheem

Isn't a better approach to not use UIDs to link so that plone.app.linkintegrity and plone.app.redirector can do it's work? I think that normally covers everything. Also, this might also be better for Plone 4.1...

comment:2 Changed 6 years ago by limi

  • Description modified (diff)

comment:3 Changed 6 years ago by dannyb

Well, there has always been a small debate about the pros and cons of UID linking and how you would solve certain problems when you don't use it. Point is that in the end all you want is create links from object A to object B and that when you move object B you don't break anything. You can achieve that in different ways but ultimately you would like to have a system that 'knows' the links. So, whether you do it by using UIDs or by using normal links and use extra managers that keep track of links and displacements, it's just a technical implementation and each has its pros and cons.

What this plip is about is actually not about UIDs but more about the fact that the user expects that when you copy a subtree that all links inside the copy remain inside the copy after the copy is completed. This includes inline links and reference links. That is exactly what collective.updatelinksoncopy does. And if you chose to use UIDs then it will deal with it. If you already use relative links then you already keep links in your copied set so the module will ignore it. Reference fields on the other hand is another matter because internally that uses UIDs to keep track of links. Collective.updatelinksoncopy also deals with references. They are kept within the copied set as well.

On a personal note I must say that we have it in production now and people cheered when we deployed it.

Additionally, it appears that all references in at least the reference field 'relatedItems' are lost when copying and pasting an object, so it would be useful to preserve these also.

This is another issue. When you set the property keepReferencesOnCopy=True on reference fields then references are kept. I have always advocated that this is default behaviour but I'm not sure if that has ever been implemented like that. Plone's relatedItems field should at least have this property set if you ask me.

Another thing: I don't think this is related to Archetypes in general. Even if we use other systems like Dexterity and other reference engines, people will still expect to keep links in the copied set so even with other systems you should deal with this situation. So this plip is a start and has implementation for Archetype based content but it should eventually be a subsystem that can deal with all kinds of object types.

comment:4 Changed 5 years ago by rossp

  • Status changed from new to closed
  • Resolution set to wontfix

PLEASE READ THIS AND RE-OPEN VALID PLIPS!

As we launch the new PLIP process we'd like to see which PLIPs:

  • are still appropriate/needed
  • still have owners/proposers/champions
  • still have available implementers

If this PLIP should still be considered for future releases of Plone please do re-open this ticket and assign an appropriate milestone. If it should be considered for the next release of Plone, use the 4.2 milestone. Also be sure to update the PLIP description, requester, owner, etc. and include a comment detailing recent progress and new plans. We will use all these details in the new continuous PLIP process.

Note: See TracTickets for help on using tickets.