My use case:

We have domains for each city. But there's no easy way to auto-group the content from a cluster of cities into a regional site, other than periodically bulk updating the nodes.

It would be useful, but not necessary, to add a bi-directional component. A sort of "publish to all affiliates" for a subset of the domains.

dru

Comments

nonsie’s picture

nonsie
she/her
Primary language Estonian
commented
Status: Active » Postponed (maintainer needs more info)

I need a bit more information for this use case. Is this from a since node edit screen perspective or bulk updates (affiliate content or node overview form)?

Let's assume you have the hierarchy set as follows:
-Regional
-- PDX
-- SEA
-- LA

If it just the node edit screen I'm assuming you would be interested in in this case is cheking "Regional" checkbox if PDX/SEA/LA is checked or doing it behind the scenes if the user does not have access to "Regional"?

There are some permission problems that need to be though through. If the user does not have permissions to publish to "Regional" but has access to SEA, PDX or LA and we allow this node to be published to "Regional" it will also become editable on "Regional" and the changes will cascade down to PDX/SEA/LA domains. What happens if for some reason this node is removed from SEA, PDX or LA or from all of them? Will it be removed from "Regional"?

I'd call this a bottom up use case since you want to publish to a parent domain in the hierarchy. There's also a complete opposite - publishing to child domains if parent domain is checked.

Patches/comments/use cases welcome.

druojajay’s picture

druojajay commented

The bottom-up case:

In the bottom-up case, I think behind the scenes makes the most sense.

The end user is just posting to the place they go to get information about their community. In my case, I'd want to minimize complexity and pare down the choices they're given. So when they post to the Seattle site, they don't see any choice of domains to post to.

But another end user might be interested in knowing what's going on in the Pacific Northwest. So they go to the regional site by that name, which displays all posts from Seattle, from Portland, but also from the Pacific Northwest site itself. (Idea being that since content gets posted to the regional site either way, there's a stronger incentive to go as local as it is relevant to go.)

In that case, you'd have a relationships admin page where I say that Pacific Northwest includes Seattle and Portland and Vancouver and whatever else, in perpetuity.

Permissions:

I'd say that the condition for something appearing in a regional site is: either it is posted to the regional site itself, or posted to one of its children. The second it is removed from Seattle, it's not in Pacific Northwest anymore. Basically you're just expanding the number of domain ids that will be allowed on a given domain.

Overlapping sets:

It might make sense to be able to have overlapping clusters rather than a strict hierarchy -- e.g. Pacific Northwest would include the aforementioned cities, but a regional site "USA" would exclude Vancouver, but add New York and Chicago.

Top-down case:

In terms of going in the other direction (top down, or regional "all affiliates"), I suppose it gets a little tricky to make all the admin functions work smoothly. But essentially, you'd have a regional 'all affiliates' checkbox for each region that's available to the current user. So if I'm a site editor on Pacific Northwest, I get the option of checking "all affiliates in Pacific Northwest", which will send the node down to Portland, Seattle, etc.

Hope that's helpful.

dru

druojajay’s picture

druojajay commented

Just tried out the module. Looks good, but flows in the opposite direction of my use case.

I propose a much simpler modification from what I proposed above:

a) Add a "none" option to the "parent" domain dropdown.
b) Make the "parent" domain a multi-select, and rename it something like "domains to inherit content from"

I'd send $50 via paypal for that change, assuming the multi part doesn't cause problems.

dru