Proposal: Introduce model Department

[jrief]

For sites which scale to many thousands of pages, it would be beneficial to separate the Page-tree into Departments, rather than Sites.

Currently each object of type TreeNode has a foreign key onto a Site objects. This is fine for multi-tenant configurations with a few hundred pages per site. It does however not scale well for sites with many thousands of pages. This is because opening the page tree's list-view becomes time consuming since users have to drill down deeply. It also requires a lot of time to compute the permissions, since all pages of a site must be fetched from the Page model.

I therefore would like to add a new model named Department which itself has a foreign key to Site. Model TreeNode would then be altered to have a foreign key onto Department instead of Site. This adds another level of indirection and can be made fully backwards compatible. It however can be used to partition the page tree into many departments and hence give users a much clearer view of the pages they are allowed to edit.

[jrief]

This could be integrated together with #7873

[marksweb]

I'm in favour of this as it might even help smaller projects. However, I wouldn't call it "Department" because that's quite specific when what we're looking for is something that groups pages or categorises them. "Department" assumes an organisation structure which may not be in place.

Maybe the groups of pages would also have their own permissions associated?

[jrief]

I like both terms, Collection and Chapter. Maybe chapter is a good analogy to page. Anyway, we must provide a way to allow nestest chapters/collections. This is to further subdivide the page tree if it gets bigger and bigger. At the University of Innsbruck, we are heading towards ~100k pages. Since books never (rarely?) have nested chapters, the term collection may be a better name.

[fsbraun]

Just as a side-remark: Collection is used by djangocms-moderation. A site could have several sections containing pages. (But then again, <section> is also a HTML tag used on a page.)

[sparrowme]

@fsbraun would this lend itself to the djangocms-categories idea you proposed a while back when the issue was brought up of tying blog entries to categories for "subscribing"... would/could that abstraction possibly fit this scenario as well?

[jrief]

The term "section" is also commonly used for CMS plugins. So this could be confusing.

[fsbraun]

@sparrowme Interesting thought! the djangocms-categories was an idea to be used to categorize any content element( like pages, blogs, etc...) It would have a generic foreign key and would be available to models through a manager (just like PlaceholderRelationField makes placeholder available).

[jrief]

Currently, the best term we found for that new model is Division. As @marksweb pointed out, the term "department" assumes an organisation structure which may not be in place.

This means that we would change the following models:

• Model Page and TreeNode will be merged into Page. This separation was required by CMS version<4 because then, one TreeNode could have more than one Page. This is a legacy now. See discussion Merge models Page with Node #7873.
• There will be a new model named Division. Its two fields are a string identifier and a foreign key onto Site. There is a unique together constraint on identifier and site.
• In model Page the foreign key onto Site will be replaced by the nullable foreign key _division onto that new model Division. That foreign key _divison is unique, meaning that there can only be one page pointing onto a given object of type Division. For root pages, the foreign key _division is required (non-nullable).
• Each object of type Page has a property named division returning the value of _division. If _division is None, it returns the value division from its parent page.

[fsbraun]

Quick feedback from the discussion at the tech committee last Friday:

• The feature is supported
• The naming should not assume or imply a specific organizational setup (like Department or Division)
• According to django CMS 4 philosophy, the preferred implementation is through a package outside the core
• Something similar (though not identical) has been done with djangocms-navigation (https://github.com/FidelityInternational/djangocms-navigation) as @NarenderRajuB pointed out
  • It allows managing the site navigation independently of the page tree through the admin (which might be part of the objective of this proposal)
  • For now, I have not found any documentation, though
  • It has been developed for django CMS 4.0, and would need some disentangling from assumptions about djangocms-versioning and the presence of djangocms-references to be used with django CMS 4.1+
• Some open questions need to be clarified about the functional scope of the proposal:
  • There was consensus that the user's view on the page tree is supposed to be restricted (which could potentially be done without changes in the model, e.g., based on permissions).
  • It remained unclear for the moment what the interaction with permissions will be: Are permissions being influenced by the new field? How can you secure that you can see all parts of the page tree you have permissions for?

@marksweb Is there anything to add from our discussion?

[jrief]

Sincerely, I have no idea how to implement this feature request as a third party package. The model Page is a fundamental part of Django-CMS and Site is built into Django itself. Therefore I would be interested in proposals on how to make this relationship pluggable.

[marksweb]

Sincerely, I have no idea how to implement this feature request as a third party package. The model Page is a fundamental part of Django-CMS and Site is built into Django itself. Therefore I would be interested in proposals on how to make this relationship pluggable.

I think this is the real point here. We've got this new version that's more powerful than any of us know because we've lost the knowledge of those who built it.

But what we do know is that through the new CMSConfig concept we can do powerful things that weren't possible before that allow apps to change functionality if they're installed.

[fsbraun]

I had some thoughts on categories before, on how to define a general categorizing model.

But the first thing needing to be clarified would be if page permissions would not allow for filtering out the subtree(s) that should be displayed in the page tree.

If not, I'd go for a nullable one2one model to the Page model. Then, the third-party package needs to have a CMSAppConfig subclass in cms_config.py which implements a configure_app method. In this method, the third-party package can inject something like the division method from the previous comment into Page using Django's add_to_class method. The admin's get_queryset might have to be adjusted, and the page tree template would have to be overwritten to include a widget for selecting the "division".