Add Category Visibility Constraint While Editing Articles

[bascherz]

Is your feature request related to a problem? Please describe.

A problem when you have a large site with many, many categories and you want your writers to focus only on the category when NEW ARTICLE was clicked and its subcategories. Permissions only indicate what that particular user can edit. They don't constrain the visibility to the category(ies) in which they need to make changes.

Describe the solution you'd like

The problem is the length of the list of categories available in the Publishing editor tab gets unwieldy. We need an option to constrain it to some scope of visibility.

The solution, IMHO, is to add an option either to the editor(s), the Articles system configuration for Categories, or to the Category itself (maybe all of the above) to constrain the visibility of other categories to the current one and its subcategories while editing (perhaps in Editing Layout). The option could be named something like "Limit category publishing scope".

Additional context

Do not confuse this with permissions. This has to do with usability.

[brianteeman]

IS this for front end article creation?

Currently you can create a menu item "Create Article" and set that to be restricted to a single specified category. I am guessing that something like that would work for you if this was a multiple category select and not a single category?

[bascherz]

Yes, for frontend article creation. The particular site layout uses categories (one per date) for allowing low-experience planners to create tiny articles for activities that are scheduled for a particular date within a multi-day event; there can be multiple activities per day. The event defines the top-level category, and each date of the event is a subcategory. When creating a new article, it is desired to present the writer with the category from whence "NEW ARTICLE" was clicked and all its subcategories as the only options for saving (publishing) the article. Since most of these folks have permission to edit articles in many other categories, the list can be very long and it can be difficult to find the right "date" (in this case).

These writers only have category/subcategory list pages to work with. When nobody has entered an article yet, there is only the "NEW ARTICLE" button at the main category. So that's all they can click. In the editor then, they select the date (subcategory) into which they want their new article to be published.

As a temporary solution, all the date subcategory titles begin with the date in YYYY-MM-DD format, so they can just start typing the date to find their subcategory quickly. But that is the only way I could figure to make it somewhat easier for them. Having a dedicated "Create Article" menu item would result in many, many such menu items. So I consider that a sub-par solution.

Thanks!

[brianteeman]

If you have a create article menu item (even hidden) then as far as I remember this is used on ALL the new article links. not at my pc to check

[bascherz]

Well, I don't consider that a good enough solution since the top-level category can change on a weekly basis and there may also be multiple such events being planned at any given time. So a single, very specific category-targeted link is not the answer IMHO.

Nonetheless, I will see if that works and maybe (just maybe) there's a solution in there somewhere. Perhaps what you mean is a menu item per such top-level category? If so, I can make that work. I'll post back here with my discovery.

Thanks, Brian. Always learning something new with Joomla!. :)

UPDATE: Nope. That did not work. At least its mere existence did not work. Perhaps there is a way to link that menu item to all those NEW ARTICLE buttons that is not automatic?

[bascherz]

As a better or additional alternative, I am now showing empty subcategories, which means all the date subcategories do appear whether they have any activity (mini articles) in them yet or not. This should suffice, but I still think limiting the categories available for creating a new article in a category or one of its subcategories should be possible.

[brianteeman]

Might just be me but this sounds like a very unique and site specific requirement

[bascherz]

At some point (pretty soon) there will be hundreds of subcategories for these inexperienced authors to choose from. It would almost be better to remove the ability to choose since saving their article in the wrong place would likely make it impossible to find. I don't think it's site-specific, but I certainly do need it for this specific site.

[bascherz]

Here's how I resolved the issue. I consider this a workaround, but it's a decent one. This post may work more as a "food for thought" kind of message.

I created a category list module positioned in the left sidebar. This shows on the page for the top-level category list menu item. (Note that none of the articles in this category or its subcategories will ever be associated directly with a menu item.) I setup the category list menu item to show empty subcategories and not mention empty categories. It looks weird at first seeing the list both in the left sidebar and down the middle of the page, but that list remains in sight (on the left) even if the writer descends into one of the date subcategories and starts editing an article there. The negative aspect of this is it could tempt them to click on another date subcategory on the left before properly closing the editor.

Keep in mind that these folks should never create an article in the top-level category, and there's really no way to prevent that since making that category not-writable propagates into all its subcategories. Perhaps I could hide the NEW ARTICLE button just on that page with CSS? Wouldn't it be nice to have a feature that closes the editor if the user browses away from it within the same browser window?

Although this does not resolve the original issue, it creates an environment in which it is unlikely they would ever have to search that entire list of categories (on the Publishing tab) when creating their article. They will simply start in the right subcategory and not have to think about it as the editor will default to saving in that subcategory. This trickery is not without its faults, but I can't figure another way that would be.