Suggestions having finished my first ezpublish project

Author Message

Arran Price

Thursday 03 March 2005 1:53:10 pm

Hi,
Having just succesffuly completed a fairly major implementation of ezpublish for a corporate intranet, I would like to share my thoughts/suggestions on what I feel are the most important things to improve on.

Firstly - ezpublish definetly met our needs and after a fairly steep learning curve weve managed to implement everything we wanted. I like ezpublish a lot.

Secondly - it appears that a high number of users are using ezpublish for internet websites and that some of the things Ive hit are unlikely to be issues for internet sites (vs intranet with many content owners).

We also had to go with version 3.4.4 due to the stage of development we were in when 3.5 was released.

Suggestions:
1. Permission system.
In a typical intranet you often want to allow access to all content but you may restrict a number of different areas which should be only for different subsets of people. You also set up a large number of content owners to manage different content in different areas. Setting this up in ezpublish can be done but can become overly complex due a bug posted (and apparently not resolved yet).
http://ez.no/community/bugs/policy_user_section_access_problem
Also sections dont overlap, so when we create sections for content owners, we have to add these sections in to a list of the sections that standard can read. We ended up with 70 odd sections and 20 roles which are over complicated but necesary for what we needed. We also created copies of the article, file and folder classes which we pre-pended the names of with "restricted" in order to give us more control of what people could/couldnt see.

A potential part solution for this is allow the nesting of sections (as per groups) and be able to set extra permissions on a section, which either are in addition to the parent section or override the parent section.
I believe you would need both and the choice of chosing what you are doing (add/override) per section.

2. Fetching
The inability to do a fetch with a combination of "and" and "or" made some of the logic for our apps very complicated, we were able to get around this by being inventive but things would have been so much easier if we hadnt had to deal with this.

3. Documentation
Ive come a long way in my ezpublish knowledge since starting this project but even with the book, the online documentation and the mostly very good community support, its a hard road to climb - especially learning the
template language. The documentation I know is continuing to improve which is great.

Next up - hopefully seeing the bug fix and then upgrading to the next version of ezpublish. Onwards an Upwards.

Arran

Frederik Holljen

Friday 04 March 2005 12:20:13 am

Hi,

First of all: thank you for very constructive feedback. These kinds of reports are appreciated a lot and will help us in future development of eZ publish.

Some feedback:
1. Permission system
I think you should be able to set up what you describe if you assign the roles with subtree limitations.
What do you mean when you are talking about nesting sections?

2. Fetching
This is something we already know about and are looking into. The problem is to make it flexible enough without creating over complicated SQL queries when you have and/or functionality.
In your case it sounds like it would be a good idea to create some custom template/fetch operators with custom SQL queries.

3. Documentation
I'm quite certain you will like the new documentation we are working on. It will ease both the learning curve and the difficulty of finding reference information. It is our top priority right now.

Frederik

Arran Price

Sunday 06 March 2005 12:07:09 pm

Hi Frederik,
thanks for your feedback, I will take a look at how to create custom template/fetch operators.

Re permissions, the subtree limitations should have worked but didnt due to the bug mentioned.
I may not quite understand how sections work but....
In regards to nesting sections, perhaps an example is the easiest way to go (note this is simplified).
If I say:
Section 1 - is "all intranet" section.
Section 2 - is my "hr" section
Section 3 - is my "hr restricted files" section
Section 4 - is my "hr content manager 1" section
Section 5 - is my "hr content manager 2" section

What I would like to do is say:
Section 1 - everyone can read everything
Section 2 - exists within section 1 but anything published here needs to go via a certain approver (in workflow)
Section 3 - exists within section 2 but only certain people can access the content.
Section 4 - exists within section 2 but has Bob as the only content manager
Section 5 - exists within section 2 but has Jack as the only content manager

If I have this and can add an "override" for the policies for section 3 (for the specific people who can read that content) and "in addition" policies for sections 4 and 5 (where I just add who can add content) this becomes very easy.

In regard to actual nesting, the way you can put groups inside groups, if you could do the same with sections, that would be ideal imho.

Hopefully that explains what I meant - or you can let me know how I should have done it (perhaps using subtrees instead of sections?). Note that we also use section identification in some of the templates for look/feel and functionality.

cheers

Arran

Arran Price

Thursday 31 March 2005 3:21:52 pm

Rather than create another thread, I will add on to this one.

Must say Im quite supprised at how slow moving this board is.

The permission issue/bug (mentioned in suggestion above) and the "bug" for links in the online editor:
http://www.ez.no/community/bugs/adding_internal_links_too_difficult
are the two major issues we currently have with the product.
Another suggestion would be to add a single release schedule/diary page to the website rather than having to read through various newsletters to find out dates (knowing wether to wait for the next release of go with the latest one when upgrading is important). If that page exists I couldnt find it.

Arran

Frederik Holljen

Tuesday 05 April 2005 5:09:31 am

We're looking into the "adding internal" links issue now and we will probably have a solution in place for eZ publish 3.6.

I'm not quite certain how you want to use sections to control what you want though. Each object has only one section at any time. The section of any parent objects is not considered. This means that it is not possible to "add" additional policies to some objects by having some section inside a section.

If you want this kind of behavior it is better to apply roles to users using subtree limitation.

Arran Price

Tuesday 05 April 2005 2:10:38 pm

thanks Frederik,
I think you are correct. The issue with managing subtrees, is with a large site its hard to manage simply because of the inability to give subtrees a name (looking at an enormous list of node numbers dosent make life easy). We used sections because at least we could name these and print out the section list as a reference.

Arran

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.