silverstripe / silverstripe-linkfield

Silverstripe module for managing links
BSD 3-Clause "New" or "Revised" License
4 stars 13 forks source link

Add many to many support for improved link editing #304

Open mooror opened 1 week ago

mooror commented 1 week ago

Description

I was talking to @GuySartorelli over on the slack channel, and he suggested I open an issue for it, so here I am :grin:

Request

I would like request many to many relationship support be added to this module so that link objects can be reused throughout the website.

Use case

On our websites we try our best to reduce the number of times we need to edit objects by making things reusable. In the case of links, this means that we create link objects (currently using the gorriecoe/silverstripe-link module) for external resources on the web and then reuse them throughout our website. Then, if that resource link ever changes or breaks, we only need to update one link object and not every place were that external URL was used.

We also use these reusable links for things like the main contact number and email for the company. We use them in headers (for call now and email now buttons) and the footer, and the contact us page. If at some point the company changes those, again we only have one place to update them.

Finally, we also use them for generic inner page links that might change. For example, a "Featured Event" link may in July link to one blog post URL, and then in August get updated to a different blog post URL.

One link object used multiple times allows us to reduce editing time and cut down on human error

Solution thoughts

Currently the single owner is needed in order for the can* permissions methods to inherit from their parent object, and for the onBeforeWrite() code that sets the sorting. As well as for any code that might use the Owner data.

For the permissions, I believe they currently fall back on the global dataobject permissions if their is no owner. Which I think works sufficiently (as the complexity level of trying to have inherited permissions with many_many seems pretty high).

I'm not sure what to suggest for the sorting code in onBeforeWrite()

Once the object itself supports many_many, the multiple field itself would need some kind of update to allow for existing links to be used. Perhaps similar to how the upload field allows you to select an existing file via a popup modal. Unfortunately I am not familiar with React, so I'm not much use in the technical area here

Disclaimer

I had to check the "You intend to implement the feature yourself *" checkbox to post this issue. And while I am willing to help if I can, I don't think I have the technical knowledge to implement it myself (especially in the React area). But I wanted to get some community feedback on this

Additional context or points of discussion

No response

Validations

elliot-sawyer commented 1 week ago

The lack of many_many support is the sole reason I'm keeping many of our projects on gorriecoe/silverstripe-linkfield module. Users are heavily reliant on existing data and it's a tall ask getting them to re-enter data for hundreds (or thousands) of links.

I've looked at migrating the links from the existing module to the new one, but at best, that would convert existing many_many links to many duplicated has_many links. That does not help the use-case being reported here, which is users wanting to re-use many links across many different pages.

I would love to help implement this feature myself, but like @mooror I lack the React knowledge to do so.