Closed Bug 398761 Opened 15 years ago Closed 14 years ago

Need hidden tags for articles


( :: Knowledge Base Software, task)

Not set


(Not tracked)



(Reporter: cilias, Unassigned)


(Whiteboard: tiki_fixed)

Need hidden tags for articles, to help track status and needs. (needs mac review, needs style review, needs updating, etc.).
This would be useful for forum threads as well.
Target Milestone: --- → 0.2
Assignee: nobody → morgamic
Would these tags be invisible to everyone?
I suppose this falls into the same jurisdiction of the staging area and article comments; so these tags would be visible to people while they are logged in.
What would be good is if we could have some sort of variable that handles stuff like this. For now, that variable would be based on logged in/logged out. Ideally, it'd be a user group or something because just because someone's logged in doesn't mean they're a contributor.
Please see the latest update on support-stage. There is now a way to set some categories as checkboxes. I have created Firefox 2, Firefox 3, and Ready for Review. Obviously, you would want to have a limited number of these, otherwise usability drops.

I suggest that most "structured" tags for articles should use the category system instead of the future hidden tags (yet to be done). The advantages of tags are flexibility and support for large numbers, which is also it's weaknesses - poor tolerance for typos and user misuse of tags.

Individual forum threads cannot be categorized, you would need to use tags. However, you can categorize entire forums.
Okay, if I understand correctly:
- these hidden tags are actually categories
- they are being hidden by way of "Exclude These Category IDs from Path" field in tiki-admin.php?page=category
Yes. You also will need to give anonymous read permission, and the registered people edit permission to these categories.

anonymous read permission? Could you explain that one for me? There are supposed to be hidden categories.
Without anonymous read permission, users can't see stuff that is inside. For now, they have to have read permission to see articles that are marked with these categories.

The confusion arises because, right now, the perm tiki_p_view_categories has 2 functions:

1- controlling viewing of stuff that has been categorized with that category (side note: a separate admin option sets the need to have perms to all vs. anyone of the categories of an object to access an object, e.g. if an object has "Staging Area" and "Firefox 3" it can only be seen by users with access to both)

2- controlling viewing of the category.

This will change soon (in a couple of weeks), to tiki_p_view_categories and tiki_p_view_categorized. It will be clearer then. This change missed last week's resync with Tiki and will be in the next. 

If necessary, we can as a temporary fix exclude these categories from view in the category browser to anonymous users through applying the settings in "Exclude These Category IDs from Path" field.
Why is this bug assigned to morgamic? 
I dunno, you're the one who did it.
morgamic, did we discuss this on the phone during the early bug triaging? Perhaps a better question: should this be reassigned to default or Nelson?
Assignee: morgamic → nobody
Actually I do not know the requirement for this bug anymore. We already have in some form the firefox 2 and firefox 3 categories, which are in a way hidden tags. If there are other specific requirements to improve this/extend this, can we file new bugs and then mark this as closed, or duplicate of these new bugs? 
I think I left it open to test the permissions issue in comment 9.

I just tried it with my Chris_Ilias_user account, and was able to browse the hidden categories; so this looks fixed to me.
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: tiki_triage nelson
Whiteboard: tiki_triage nelson → tiki_fixed
You need to log in before you can comment on or make changes to this bug.