- Status New
- Percent Complete
- Task Type Feature Request
- Category Backend/Core
- Assigned To No-one
- Operating System All
- Severity Medium
- Priority Very Low
- Reported Version 1.0 alpha1
- Due in Version 1.1 devel
-
Due Date
Undecided
- Votes
- Private
Attached to Project: Flyspray - The bug killer!
Opened by peterdd - 18.07.2015
Last edited by peterdd - 09.09.2015
Opened by peterdd - 18.07.2015
Last edited by peterdd - 09.09.2015
FS#2012 - Managing Tags
Tags can only be added on the "new task" page, not managed on the "edit task"-page.
ID | Project | Summary | Priority | Severity | Assigned To | Progress | |
---|---|---|---|---|---|---|---|
2102 | Flyspray - The bug killer! | Low | Medium |
After looking and working a bit on the tags feature I come to the point where I think it is better to change the db tables now. Instead of trying to make it a bit useable with the current (non)implementation and reworking it later.
The current situation is that the tags at the moment are not useful. They aren't show in task list, not filterable, not searchable, and not stylable (colors!, icons!
)
And losing the few tags who are exists in FS1.0dev installs do not hurt, IMHO.
Instead I prefer simply changing table tags from current
to
This db table change is IMHO a better start for the tag feature and can later more easily extended without brain damage of the developer.
(like additional fields or other tag related tables like "tag_translation" or "tag_synonym".)
I start with a field class in tags, which can contain a string of css classes.
When having a standard set of cssclasses for tag styling (lets say 10 colored slightly round edged with background and 10 that show an icon :before or :after tagname), these can be easy combined by the user and look nice.
Since today the basic tag feature is working the way I had in mind.
What still is missing:
address each tag with .tag.t123 in css if you can't wait and know the internal id of the tag (the tags are written as
Edit 2015-11-12: modified for changed class scheme class="tag t123"
Hi Peter and others,
Before starting, I have some questions about this feature:
What do you think about those?
"Do you already have some design tools in mind for admin project part?"
As starting point I think we can go this way:
Adding the permissions you mentioned seems logic. But we have still so much permissions (nearly 30 per install and per project)
Before going tag permissions I would prefer implementing search/filtering by tags.
The creation of new tags can also be denied in the project settings, so we still have some control over tags.
"We should consider tagging/untagging a task as a modification, for notifying and reports?"
Yes, any add/remove of tag is a modification, so logging and notification should be made. But notification on change is incomplete also in other areas in Flyspray, so there is still enough work (see includes/modify.inc.php for example TODOs).
One uprising problem is that the more complete the notification system gets, the more spammy the notifications could be to the users, especially with the "quickedit"-feature. One possible solution to that would be grouping notifications together if requested by user (e.g. a user setting "send only 1 summary of changes per day for a task/ a project". But that's another story...