SiteRelated, ManyToMany instead of ForeignKey

[Josh Cartmell]

I have a client who may be wanting me to modify Mezzanine's site
handling to allow content to be associated with multiple sites, rather
than just a single one. This has been discussed before and a number
of problems and things that would need to be considered further were
brought up. The discussion is here:
groups.google.com/group/mezzanine-users/browse_thread/thread/
e173dee4c683e05c/

notably:
- What happens when a child page gets assigned to a second site that
doesn't have the parent?
- How can the page's _order field (for ordering) be used which it's
relative to the other pages on that branch? We'd need to break
ordering out
into its own table that stored page IDs, site IDs and _order values -
not
sure if it's the right approach or not, but either way it's a big step
from
how it is now.

I am wondering if there is any interest in this in this idea in the
wider Mezzanine community. I was also wondering if anyone had any
comments on any further considerations that would need to go into
this? I would ideally want to make this in such a way that it could
be pushed back into Mezzanine core.

Alternatively, would it be feasible to provide an additional Mezzanine
sites mixin that would allow certain content types to use a ManyToMany
and others (pages) to use a ForeignKey, since most content types
wouldn't have to worry about order or parents the same way pages do
since they don't have a hierarchy.

The client would also like the ability to manage permissions for admin
users that would restrict which sites they could access. Is there any
interest in or thoughts about that idea?

Regards,
Josh

[Stephen McDonald]

Firstly, everything you've described is a welcome change. I think it represents the next level of multi-tenancy in Mezzanine, and ultimately we'd end up with sites as a manytomany field *everywhere*. However I think it'll require some significant changes.

On Thu, Aug 9, 2012 at 9:58 AM, Josh Cartmell <joshc...@gmail.com> wrote:

I have a client who may be wanting me to modify Mezzanine's site
handling to allow content to be associated with multiple sites, rather
than just a single one.  This has been discussed before and a number
of problems and things that would need to be considered further were
brought up.  The discussion is here:
groups.google.com/group/mezzanine-users/browse_thread/thread/
e173dee4c683e05c/

notably:
- What happens when a child page gets assigned to a second site that
doesn't have the parent?

Please tear this idea apart as I'm sure it has flaws. I think what we'd need to do here is somehow filter the sites that can be chosen from based on the parents. Eg: with sites A, B and C: page called "primary" gets added to sites A and B. When adding a child page to "primary", only A and B would be available as related sites to add to.

 

- How can the page's _order field (for ordering) be used which it's
relative to the other pages on that branch? We'd need to break
ordering out
into its own table that stored page IDs, site IDs and _order values -
not
sure if it's the right approach or not, but either way it's a big step
from
how it is now.

Yes that's a big step and the correct one. Ordering would need to be implemented in a separate site-specific table which would contain a site ID, page ID, and order value.

 

I am wondering if there is any interest in this in this idea in the
wider Mezzanine community.  I was also wondering if anyone had any
comments on any further considerations that would need to go into
this?  I would ideally want to make this in such a way that it could
be pushed back into Mezzanine core.

Alternatively, would it be feasible to provide an additional Mezzanine
sites mixin that would allow certain content types to use a ManyToMany
and others (pages) to use a ForeignKey, since most content types
wouldn't have to worry about order or parents the same way pages do
since they don't have a hierarchy.

I think for consistency's sake in the database and models it should be one or the other. If we want things to only be related to one site, we can have a way of not having the sites field editable via the admin, and a single site can be implicitly assigned based on the current site. Again please tear this apart if you can see flaws.

 

The client would also like the ability to manage permissions for admin
users that would restrict which sites they could access.  Is there any
interest in or thoughts about that idea?

I think this a wider feature that applies to more than just sites, that is, object level permissions. I think if we solve that problem at a wider level, the solution for sites would become clear.

 

Regards,
Josh

--
Stephen McDonald
http://jupo.org

[Josh Cartmell]

Thanks for the feedback Steve, I definitely think it will be a big undertaking.  I'm glad that there is interest in the idea here, I will try to keep the list updated with any progress I make.  It will probably be awhile still before I start in on it but I wanted to start the juices flowing.

I agree that children should only be able to be added to sites that their parents belong too.  If you remove a site from a page I envision an intermediary page after saving that would inform you if children pages will be removed from sites at all (similar to how when you delete an object there is a page which tells you which related objects will be deleted).

The table structure you suggested for ordering sounds good to me.

I'll keep thinking about how permissions would fit into this.

If anyone else has suggestions or comments I would be very open to them.