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 <joshcar
...@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.
--
Stephen McDonald
http://jupo.org
