This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit ezplatform.com

eZ Community » Forums » General » Multiple Section Assignment
expandshrink

Multiple Section Assignment

Multiple Section Assignment

Thursday 12 June 2003 12:05:46 am - 21 replies

Is it possible to assign an article to multiple sections? something to the effect of what this page talks about:

http://ez.no/developer/ez_publish...multisite_sections_assign_folders__1

and this suggestion page addresses:

http://ez.no/developer/ez_publish...ions_of_pages_with_muliple_locations

I want to display identical data within two completely different page layouts (ie pagelayout_section_1.tpl and pagelayout_section_2.tpl) and that's only possible if I am able to assign the very same object to two different sections. I know you can have an object assigned to multiple places, but there is no way, that I have seen, to assign an object to multiple section_ids

I really need help on this one....
I have tried it using eZ publish 3.0, 3.1 beta 1, and beta 2. I've also tried going into the mysql tables to manually change it, but to no avail....

Thanks,
Adam

Thursday 12 June 2003 2:42:22 pm

I'd think this would be possible if you assign your article to two different nodes. You can then assign your two sections to the nodes as you wish and it should work.

Karsten

Thursday 12 June 2003 6:59:52 pm

No this does not work (all versions, inlcuding 3.1beta2), and I consider this to be a serious design flaw. It does not take the parent section id for the new node, but from the original node the object was assigned to.

You can easily test this with a the demo setup. Add for example a new location to a forum message to "my site". A link shows up in my site to the message, but when you click the link, the full view mode takes the section id and hence the pagelayout from the *original* node: you are forced back to the formums page layout.

So the publish in multiple nodes currently does not offer more than a "link". It behaves as a "related object".

Also, when you add multiple locations, child nodes for these two are completely independent. This may be desirable in some situations, but for others this is counter-intuitive. Here ez publish needs to be polished. It is probably not a matter of choosing behaviour A versus behaviour B, but the possibility to choose between behaviours A and B.

What do others think? What was the original design idea for multiple locations by the ez team and the issue of section ids?

--
edit: please respond a little to this, I want to file a bug report but want to make sensible alternatives to the current behaviour.
--

Regards

Paul

Modified on Thursday 12 June 2003 7:02:55 pm by Paul Borgermans

Thursday 12 June 2003 9:50:36 pm

Thank you for your replies Paul and Karsten.

Paul, I could not have said it any better myself. I really need this particular item to work and you have hit the problem on the head. I've even gone into the database to see if I could change it manually, but that didn't work either. I attempted to file a bug report yesterday, but I'm not nearly as consicely specific as you in explaining this. Please let me know if there's anything I can do to help.

Could section ids be assigned on a node by node basis when adding multiple nodes?

Thanks,
Adam

Modified on Thursday 12 June 2003 10:20:43 pm by Adam Keaton

Friday 13 June 2003 12:22:21 am

Hi Adam

I've also come across this issue and it has lead me to reconsider how I use sections in a site.

The issue is that the section_id is associated with a content object and not the node. The node "tree" contains pointers to content objects, so if an content object exists in multiple locations within the tree the same section id is used (as it is associated with the content object)

I think there may be a design flaw in this, but only in so much as how sections are used. Sections can be used to control both pagelayout and permissions. I'm not sure that combining these two things is a good idea.

I was under the impression that the new override system in 3.1 would solve this problem but unfortinually I haven't spent enough time with it yet to investigate this fully. I think these is where you have to look.

Hope this helps,
Bruce
designIT

Modified on Friday 13 June 2003 12:24:55 am by Bruce Morrison

Friday 13 June 2003 12:53:19 am

This should probably go in the developer forum but I'll continue the thread here.

On further thought the dual use of sections for page layout and sections is the issue. These two functions need to be separated out into layout sections and permissions zones.

Page layout should be associated with the node tree. This would mean that the current section id should be able to be associated with a specific node. When placing a content object in a node tree (location) the new node should inherent the section_id of the parent node. This would allow for the same piece of content to be displayed in different page layouts.

Permissions should be two fold. Content type permissions associated with content types would allow for complex content objects to be created and maintained. An example of this would be product content type having reviews as a child content type.

Instead of using sections, the concept of a security zone could be introduced. The security zone would be associated with the content object (as sections ids are currently).

Section ids are currently associated with content object because of the permissions system. If a content object exists in multiple locations and the section id was inherited from the parent node, then it may be possible for a user to edit/delete/create content in one location, where they shouldn't be able to.

I realise this may not be a clear solution, but I am confident that the dual function of the sections is an issue that should be addressed.

Cheers
Bruce
designIT

Friday 13 June 2003 11:17:54 am

Bruce, I haven?t looked into the technical solutions of 3.x, but if a part of an object is used for two different purposes (as you suggest) then it is clearly a design flaw.

In fact separating content from design is one of the purposes of eZ publish, and having both the security and the site design being decided by one attribute of an object is clearly mixing of design and content.

I can?t really believe it has been done, but I haven?t done much testing of 3.x, I just have to say I am surprised.

Paul

Saturday 14 June 2003 12:47:01 am

Bruce & Paul,

Could one of use file a bug on this? The feature in questions is one of the main reasons I picked this CMS. I guess I took it for granted that ez Publish did this and it seems like it was listed as a feature somewhere on the site. I am desperate for this issue to be fixed. Do you think that it will be addressed in future releases? If not, I'm in a bad spot and will have to look for another CMS package and I really don't want to because I've invested huge amounts of time (ie money) and it's really a good package aside from this problem.

Thanks,
Adam

P.S.
Could this issue already be addressed somewhere on the paying support system?

Modified on Saturday 14 June 2003 2:09:07 am by Adam Keaton

Sunday 15 June 2003 3:00:12 am

If you look at the database tables the section_id is clearly associated with a content object not the node. Within the current design I believe that this is correct. However it leads to the limitations described earlier in this thread.

I view this more as a design limitation than a flaw. happy.gif Emoticon

I'm interested in hearing any comments on this issue from the ez team as I believe that changing how the sections work is a major low level change.

Cheers
Bruce
designIT

Monday 16 June 2003 2:48:24 pm

I will try to clearify how we designed the sections to work. The sections were mainly designed to work with permissions. Think about the scenario on an intranet where you have the frontpage of the intranet which is readable by everyone. Then you have two categories which are readable by two different groups:

Frontpage
News A
News B
News
Accounting
News A
Development
News B

Here you have two roles one which have permission to ready the accounting category and another which is able to read the development category. The stories published under these categories are also published under the frontpage. This means that when viewing the frontpage you will only see the news articles that you have permission to see.

That is the reason for sections beeing connected to the object and not the node.

For having a specific design for the frontpage category you would need to define an override for the subtree. Subtree design override is planned in eZ publish, but it's not yet implemented.

--bård

Monday 16 June 2003 3:09:41 pm

Since showing the same module outputs in different page layouts is a basic feature of version 2 I assumed the sections worked in a similar fashion in version 3.x.

What's the schedule on the subtree override? Is there any way to imitate this with the current code? Sorry to ask before investigating, but I think this is a critical point.
On the developer side, I would agree with Paul & Co. that attaching pagelayouts to objects is not the best idea. In fact, IMHO the override system should ignore the object altogether and only be controlled by nodes.

Karsten

Monday 16 June 2003 3:12:45 pm

Karsten: I agree that this should have already been in 3.0. The way it's done in 2.2 is that we have the category ID in the URL, that way we know from which list the article was linked from.

I'm soon finished with the implementation. I will just test it a bit and will commit it within one hour to trunk. It will then be available in 3.2.

--bård

Monday 16 June 2003 3:41:06 pm

I've just commited support for subtree overrides in revision 2737 (trunk).

You can now check if the node is under the defined subtree. Example of configuration:

[searchfolder]
Source=node/view/full.tpl
MatchFile=product_under_frontpage.tpl
Subdir=templates
Match[url_alias]=frontpage

[searchfolder]
Source=node/view/full.tpl
MatchFile=product_under_frontpage_news.tpl
Subdir=templates
Match[url_alias]=frontpage/news

The system uses the url alias function of eZ publish to determine if you are under the desired subtree.

I hope this solves the problems you've experienced with sections.

--bård

Monday 16 June 2003 5:09:21 pm

Thanks Bård,

This solves (almost) all of it. One suggestion perhaps for the future: allow for multiple Map[url_alias] entries which are 'or-ed' together. Or allow for definition of some layout-realms which can be assigned to different node-trees (in the way you can do with sections now).

I also think the entries to section id's should disappear in the future to disconnect the persmission system entirely with the layout.

Best regards

--paul

Tuesday 17 June 2003 3:12:30 am

Let me add my thanks!

I've got the latest revision running (2738), however I'm still not sure about how to specfically apply this fix. Could someone post an example of how to apply the fix (ie a more specific example with explanations of every step)? I'm not even sure what specific file the code from above applies to.
In which file are these entries supposed to be placed?
Does the fix work through the URLTranslator and if so is there a setting that I need to be changing after the default install to get it working?

Thanks all,
Adam

Modified on Tuesday 17 June 2003 3:22:08 am by Adam Keaton

Tuesday 17 June 2003 4:22:39 am

Bård thanks for the explanation of sections. I think that once the subtree design override is complete things will be more flexible from a layout point of view and sections can be used just for permissions.

On another note, the latest beta seems to allow for permissions to be set on particular nodes or node subtrees (although this functionality looks to be incomplete at this stage).

I'm not sure that allowing permissions to be associated with the node tree is a good idea (ideally they should be associated with the content objects as they currently are with sections).

By associating permissions with a the node tree the scenario where a content object has multiple locations with in the node tree could lead to an article being editable/deletable in one position but not another.

Any comments?

Cheers
Bruce
designIT

Tuesday 17 June 2003 9:20:58 am

Bruce: the node and subtree permissions are very handy since the section concept can be limiting.

It's true that this can make some problems when assigning an object under different subtrees with different permissions. But it gives alot more flexibility and on some setups it would be too much overhead to create sections for a single node.

We're of course open for suggestions on how this can be solved.

--bård

Tuesday 17 June 2003 6:08:32 pm

>Bruce: the node and subtree permissions are very handy since
>the section concept can be limiting.

Agree completely

>It's true that this can make some problems when assigning an
>object under different subtrees with different permissions.

Yes, human errors...

>But it gives alot more flexibility and on some setups it would
>be too much overhead to create sections for a single node.

>We're of course open for suggestions on how this can be
>solved.

Perhaps clone the section idea for layout as a realm to permissions. So besides the possibility to define a section and assign it to one ore more node trees, allow for permission realms to be created which can then be applied to one or more nodes or node-trees.

You may also forget my suggestion to remove the sections from role settings, or replace this by the possibility to let a permission realm be coupled to a section realm.

--paul

Modified on Tuesday 17 June 2003 6:08:53 pm by Paul Borgermans

Tuesday 17 June 2003 6:34:13 pm

Hi all,

I'm "just" reading that thread with a lot of interest. We have no need for permission and layout "realms" yet, but we will, when we migrate from 2.2.

As I see the discussion now, sections in ezP3 have the primary objective of setting permissions, not design. This is a contrary concept to sections in ezP2, which served for Design (Layout, Language, Templates).
Plus, Permissions in ezP3 are Node-specific, not object (=content)-specific. While this may be nice in most situations, it's not the concept of ezP2 (I don't say, that it is better or worse... but different!).

So, PLEASE note the changing of these concepts and terminology for users, who know ezP2 and/or want to migrate a ezP2 system to ezP3!!!
For new ezP3 users, this is not needed, they will just be confused, but it would be a good topic for a "Upgrade Guide" or "What's different in ezP3 vs. ezP2". Community contribution somewhere?
As this is a serious and far-reaching topic (concerning permissions AND design concepts), this should be written by someone, who has a full understanding of it (=not me, yet blunk.gif Emoticon ).

Modified on Tuesday 17 June 2003 6:34:55 pm by Marco Zinn

Tuesday 17 June 2003 8:07:26 pm

Hello all,

Where can subtree overrides be configured and how? (am I on the right track?)

I've done a search for 'subtree override' but nothing but this thread comes up.

Also, will the final release of 3.2 have this fix somewhere in the documentation?

-Adam

Modified on Wednesday 18 June 2003 12:41:10 am by Adam Keaton

Wednesday 18 June 2003 3:14:04 pm

This has basically been added as we speek (so there is no other info around, yet) and will be in version 3.2 (that's what Bard said, anyway). I think the release plan for 3.2 will be published as soon as 3.1 final is out (June 25). Maybe they put it in 3.1-2?

Anyhow, if it is important, get the files from svn and hack it into 3.1. I think this should be possible.

Karsten

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from