Folders with "index document" has several UI inconsistencies

[sergey_v]

1. Duplicated search entries. Search for string "News", for example, returns two entries, folder /news and Smart Folder /news/news_topic, both links (from user point of view) lead to the same place.

2. Folder listing looks differently in different circumstanses. Example:  http://mysite/news/ shows no entries in folder and  http://mysite/news/view shows "news_topic" Smart Folder. Some links on site lead to either of this urls (see Search Results entries)

3. Title and Description of Folder and its "index document" are out of sync. It could be confusing even for expirienced user - if one click "News" link and edit that object (change title and description) - page title and description will change, but navigation portlet won't reflect this changes.

[alecm]

1. This is a tricky problem. We could optionally exclude default pages from searches (as the navtree does), but this would make it impossible to find default pages based on their attributes or content when different from the containing folder. Not searching folders that have default pages set may be better, but it would require some new methods/indexes, and would suffer similar drawbacks. The objects are not the same, the folder itself is a distinct content object, though that may be obscured by the use of default pages.

2. This seems like it might be a browser default or method alias bug. Optilude will know. Shouldn't /view return the default page, or does it always render the selected layout? If the latter, why?

3. I can see how this might be confusing, however I'm not sure that syncing properties between the two is the appropriate solution. This is a policy issue in some sense. I'm not sure we want as tight a coupling between objects and their default views as you think is desirable. Perhaps one could use Five Adapters to handle this sort of thing gracefully when desirable.

[optilude]

1. Don't know about the search behaviour here. I'll leave that up to Alec to think about.

2. It's not a bug. If there are links pointing to /view they should be carefully considered. The expected behaviour, to retain backwards compatability and make it reasonably easy to get to an object itself consistently, is that /view always views the object as it would be displayed regardless of any browser-default settings. So /path/to/folder/view means show the folder, even if it has an index_html or other default-page. If you have links pointing to /view you need to find out where they're from and why. (this also applies to files and images, where /view gives you the view of the object in plone, and the direct path gives you the file content)

3. We did talk about this a lot during the UI sprint. We came down to the fact that there are good use cases for keeping them separate. You can go via the 'contents' tab to get to the folder edit screen. We may also want to consider something where a link on a document edit screen can take you to the folder edit screen if the document is a default-page, but we haven't settled on how his may work.

[alecm]

So these are purely usability issues, and tricky ones at that. Reassigning to limi our overlord of usability.

[limi]

Not going to touch these in 2.1.0, we'll see what we can do in 2.1.x.

Not sure I agree on the current /view behaviour, but we'll discuss this and see if we can find a good approach.

[pupq]

#3: We have the right behavior; syncing would be wrong. Classic case: a folder called "Press Center". Inside that, a default document called "Welcome to Our Press Center".

If people find it confusing, we should address that with docs/UI, but syncing the two is not the way to go.

[limi]

I believe the only of these three issues that we should consider is the "you are currently editing the default view of a container, if you want to edit the container itself, go here".

[limi]

…which is implemented in 3.0.