File tagging should support the attachment of 1-n arbitrary tags to a file and container. The tags can be used in 1) searching and 2) as a report qualifier. Tags should be short but may contain multiple words.

Decision: Given the requirements, and some vision for the future, are tags the method we should implement?

If so, then refine into implementation tasks and database changes needed. If not, then what?

The HP OSRB has requested some method to keep track of where packages/files are in the review process. My thought is that tagging would be a good solution for this and perhaps other uses as well. For the OSRB, they would like to create tags like “Done”, “ToDo”, “CTO Approved”, “In progress”, etc. Currently they use a spreadsheet which is a pretty poor solution. Tags would give everyone doing reviews real time updates of what needs to be done.

The search menu item should be revised to include tag searching. However, the main use case for searching for tags isn't at this global level, but the ability to search in a file hierarchy. A “search” link needs to be in the micro menu and that should include search for tags. To implement this in the micro menu, because of the clutter in this menu, we need pull down lists in the micro menu. In this case clicking on “Search” in the micro menu would bring up options to search for filename, tag, or whatever. This could be implemented in a future version.

This critical feature allows reports to filter results based on tags. For example, on a nomos license report there could be a tag input that filters the results based on which packages are tagged “Needs CTO review”, or whatever. For example, to filter on “Needs review”, one would simply enter “Needs review”. The user should be helped by autocompleting the tags where the user is shown the tag options once they start typing.

In a future release, this might be best done with a simple grammar to allow conditionals. To specify either of two tags, one could enter “tag A or tag B”. A simple grammar could handle “and”, “or”, “not”, ”(”, ”)”. I don't believe we need to do this for the first implementation.

Some tags should be public. Some tags should only be visible to a group which means each group would have their own namespace. “Public” is just another namespace. Implementing groups is the most difficult part of adding a tags feature because it cascades to everything else in fossology. However, to keep feature creep down, in this revision only tags would use groups.

Of all the ways of implementing permissions (role based, owner/group/other, ACL's), I think owner/group/other is the simplest and would do everything we need.

1. Cascading A user should be able to cascade tags at any level of the file hierarchy. For example, you could tag an iso and cascade the tags to every file, or restrict the tags to packages. Or you could delete a tag for a package and it will effect every file in the package.
2. Buckets setting tags The agents need the ability to set tags. For example, one might want to have a bucketpool that sets every package in a distro to “Needs Review”, except for packages that have been previously passed review and have no significant license changes.
3. Buckets using tags Tags could potentially be used as criteria for buckets. For example, the bucket for “packages that have been previously approved and contain no new licenses” could make use of the “Approved” tag.