498056 - Force non-KB articles to have a category

Status: VERIFIED FIXED

(support.mozilla.org :: General, defect)

Description

[Paul Craciunoiu [:paulc]]

I was playing around trying to figure out bug 489874, and I managed to create a staging article with no category (by itself). I saw there's an option in the preferences called "Force and limit categorization to within subtree of:" (on the "Wiki" admin page). We should make that work and assign it to "All", just to enforce no non-categorized pages.

This is somewhat related to bug 489874, but the fix for this does not address that issue, so I thought a separate bug might be better.

Patch to follow.

Comment 1

[Paul Craciunoiu [:paulc]]

Attachment: patch v1

There's some duplicated code in tiki-editpage.php that doesn't allow the pref for mandatory category to be set. This patch removes it from those two places. Since the "if"s check only globals or superglobals, the values aren't expected to change over time.
Furthermore, the smarty variables 'category_needed' and 'contribution_needed' are assigned in more than one place. This patch only keeps the final assigns on lines 421-422 (line #s after patch)

Comment 2

[Paul Craciunoiu [:paulc]]

(In reply to comment #1)
> Created an attachment (id=383066) [details]
> patch v1

I was just thinking this may not work for other tiki-editpage.tpl templates. So I guess hold off on this until we also make the editor page same for all categories.

Comment 3

[Paul Craciunoiu [:paulc]]

This bug could alternatively be turned into a new optimization of tiki-editpage. Untargeting for 1.2 right now since the idea I initially had may require significant QA.

Comment 4

[Laura Thomson :laura]

So is review still needed?

Comment 5

[Paul Craciunoiu [:paulc]]

Comment on attachment 383066 [details] [diff] [review]
patch v1

No. Though we should still force articles to have a category somehow.

Comment 6

[Paul Craciunoiu [:paulc]]

Ideally this bug will patch the article-creation/update code to make sure a category is added under all circumstances. There should be a check, right before save, that automatically picks the staging area.

Comment 7

[Paul Craciunoiu [:paulc]]

After some investigation, articles using the "other" editor (with multiple categories) can be created in no category. Should we force them all to be in a category?

STR:
1. Edit a How to Contribute article. Uncheck "Categorize this object" or unselect all categories

Actual results:
Page is in no category.

Comment 8

[Paul Craciunoiu [:paulc]]

Attachment: patch, v2

This is an improvement over the patch in bug 504265. What the patch does:
* Creates a pref for forcing ALL articles to be in at least one category. If disabled, the behavior should be the same as before 1.2.1. However, if enabled, any save of an article should check to see if the article has one of the categories in the list from the pref. This ensures, finally, that all saved articles have a category. The list should be set, by default, to "1,3,7,8,20,23,24" -- which is the list of categories that show in the path.
* Removes the "categorize this object" checkbox from the editor if the pref is enabled (since we want to categorize all articles). This is done by copying categorize.tpl over to mozad and linking to it from all other themes that use it.

With this patch it shouldn't be possible to create articles in no category any longer.

Chris, does the behavior of this sound good to you?

Comment 9

[Chris Ilias [:cilias]]

(In reply to comment #7)
> After some investigation, articles using the "other" editor (with multiple
> categories) can be created in no category. Should we force them all to be in a
> category?

This has been happening when people try to translate KB articles. The people creating them don't have permission to edit/translate HTC pages.
Example <https://support.mozilla.com/en-US/kb/print?bl=n>

Comment 10

[Laura Thomson :laura]

Comment on attachment 390520 [details] [diff] [review]
patch, v2

Be careful with the symlinks when committing otherwise good.

Comment 11

[Paul Craciunoiu [:paulc]]

r48211 / r48212

Comment 12

[Vishal Kamdar [:vish_moz]]

Verified, FIXED.

Comment 13

[Paul Craciunoiu [:paulc]]

Looking at this, I'm thinking maybe forcing articles to have EXACTLY one of the radio button categories is better. The current implementation forces them to have AT LEAST one. This is a problem, for example, because you can accidentally have an article in both HTC and staging.

What do you think, Chris?

Comment 14

[Chris Ilias [:cilias]]

I think that's a theme issue, which using the same editor for all articles should fix. If I try to edit an article on prod in the staging area (e.g. <https://support.mozilla.com/tiki-editpage.php?locale=en-US&page=Test+kb+rename+old>), I cannot assign it to both HTC and the staging area. Whereas if I edit an article in the HTC category, the category selector lists all categories in one box, allowing me to select more than one.

Comment 15

[Paul Craciunoiu [:paulc]]

Agreed. So how serious of a problem is this? Should we do anything about it yet, or wait until the editor milestone?

Comment 16

[Louis-Philippe Huberdeau]

Just trying to sort it out.

When this was implemented, was mandatory category considered?

Based on my code reading, it seems to verify if any of the forced categories were assigned, and if not, it adds the staging category. Is this correct?

In upstreaming this, I would make it independent from staging. Perhaps a separate preference to specify the default categories.

Comment 17

[Paul Craciunoiu [:paulc]]

Sounds good LPH. We want all pages to have at least one category from a set list, and if none is selected then fall back to a default. From what I understand, you need to upstream the pref for the list of categories, and create an additional pref for the default fallback. Right?

Comment 18

[Louis-Philippe Huberdeau]

Added the category_defaults preference to configure the whole thing. Configurable from Admin > Categories. Multiple sets with different defaults can be specified.