Advancing open source analysis and development
|
FOSSology Advancing open source analysis and development |
This shows you the differences between the selected revision and the current version of the page.
| tagging 2010/07/28 15:30 | tagging 2010/09/02 00:59 current | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ===== Tags ===== | + | ====== Tags ====== |
| - | 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. | + | Tags are short text labels (with an optional notes field) attached to a physical file (pfile_pk). Tag selection and visibility will be in: |
| + | - Searching | ||
| + | - Reports | ||
| + | - Report filters | ||
| - | ===== >>>> Next Step <<<< ===== | + | Because of their organizational and possibly confidential nature, tags are defined in their own namespaces (0 - n tags in each namespace), and there are 0 - n groups assigned permission levels to access each namespace. Related information about permissions can be found on the [[perms | permissions page.]] |
| - | **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. | + | Here are the [[tag_group_tables | table definitions and relationships]] for the tag and permissions (group) tables. |
| - | If not, then what? | + | |
| + | The following shows how tags are defined internally and how they are associated with files. | ||
| + | |||
| + | ===== Next Steps ===== | ||
| + | **Mockup UI, database tables, then review with OSRB and any other interested users** - this is currently in process, although we currently have no participants other than HP's OSRB. | ||
| + | ====Task list & Plan & Status==== | ||
| + | * Requirements discussion and Mockup UI. **Done by Bob** | ||
| + | * Tagging implement design and Database table design. **Done by Bob** | ||
| + | * Code a small proof of concept to verify Bob's design idea. **In process by Bob** | ||
| + | * Database changes implementation. Bob have created the database table sql, Vincent will use the sql to implement the database changes and verify if any issues. **In process by Vincent, estimate end by Sep 2** | ||
| + | * UI implementation to attach/edit/delete 1~n tag (1 or 2 words) to a file or container **Estimate end by Sep 7** | ||
| + | * Tag the file only | ||
| + | * Tag the container and all files it contains (recursively tagging) | ||
| + | * Tagging permission implementation. **Will have dependency with Group task, estimate end by Sep 10** | ||
| + | * Tag namespace management | ||
| + | * Assign tag namespace permission | ||
| + | * Searching **Estimate end by Sep 15** | ||
| + | * The search page will be revised to include tag searching | ||
| + | * The ability to search tag in a file hierarchy. A “search” link needs to be in the micro menu | ||
| + | * Report Qualifier **Estimate end by Sep 20** | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | ===== Requirements ===== | ||
| + | ==== OSRB Requirements ==== | ||
| + | The HP OSRB has requested some method to keep track of where packages/files are in the review process. We are going to use file/container tags as the method. Tags will have 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 instead of a real-time solution. Tags would give everyone doing reviews real time updates of what needs to be done. | ||
| + | |||
| + | ==== Raino Requirements ==== | ||
| + | FOSSology is a good license scanner but a company user has a wider OS governance view for the OS components. | ||
| + | Tags could be used for that purpose by including text with a tag. This could be used to associate some reasoning with the file. Eventually FOSSology could be the place for all the company's OS governance data. | ||
| + | |||
| + | |||
| + | ===== Tag usage ===== | ||
| + | |||
| + | ==== Tagging ==== | ||
| + | |||
| + | You tag a file (or group of files) [[tagbrowse|while you are browsing]]. If you have write permission to the tag, you will also have options to edit the tag and tag text, and delete the tag. If the file you are browsing is a container, then you also have the option to cascade the tag or tag delete recursively to every single file inside the container. | ||
| - | ==== Requirements ==== | ||
| - | 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. | ||
| ==== Searching ==== | ==== Searching ==== | ||
| - | 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. | + | 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. For example, [[http://fossology.org/_media/search-minimenu.gif?w=120&h=89 | here is how it could look. ]] |
| + | |||
| + | Clicking on that search link would bring up the [[http://fossology.org/_media/newsearch.gif?w=120&h=89| new search plugin (search.php)]] | ||
| ==== Report Qualifier ==== | ==== Report Qualifier ==== | ||
| Line 20: | Line 68: | ||
| 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. | 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. | ||
| - | ==== Permissions ==== | ||
| - | 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. | + | ==== Process to get started tagging ==== |
| + | |||
| + | To get started tagging, you need a fossology admin to: | ||
| + | |||
| + | - Create a group or groups so you can later give them permissions in the tag namespace. Creating a group writes to the group table. | ||
| + | - Assign members to the group. This writes to the group_user_member and group_group_member tables. The admin only needs to assign one user member or group member and give them admin privileges to the group. Then those users can add/delete user and group members and assign their gropu permissions. | ||
| + | - Create a tag namespace. This writes the namespace name (like "my review process", or "my project tags") to the tag_ns table. | ||
| + | - Give a user or group permissions to use and/or admin the namespace. This writes to the tag_ns_group table. | ||
| + | - Any tag namespace admin (assigned in tag_ns_group) can create add, delete, and assign assign permissions other namespace users (more tag_ns_group entries). | ||
| + | - Finally, anyone with read/write or above (admin) privileges can tag files. Tagging a file writes table tag_file records. Typically tagging is done while [[tagbrowse|while you are browsing]]. | ||
| + | |||
| + | |||
| + | ===== Tag namespace definition ===== | ||
| + | Tags are managed on the namespace level. So each tag namespace has a list of member groups and their permission level. A default namespace should be added to the users table, but users should also be allowed to switch namespaces, just as they can switch buckets, at runtime. Of course, they should only see tag namespaces for which they have, at least, read access. | ||
| + | |||
| + | Tags are not shared across namespaces. | ||
| + | |||
| + | This is the tag namespace table. | ||
| + | |||
| + | ==== Table: tag_ns ==== | ||
| + | |||
| + | ^Column ^ Type ^ Key ^ Function ^ | ||
| + | |tag_ns_pk | | Primary Key | | | ||
| + | |tag_ns_name | varchar(32) | Unique | The namespace name | | ||
| + | |||
| + | |||
| + | ===== Tags ===== | ||
| + | Tags are members of namespaces. Each namespace has 0 - n tags in it. Tags are not shared across namespaces. | ||
| + | |||
| + | Since tags are meant to be short labels, their length is restricted (arbitrarily) to 32 characters. Their text is restricted to printable text (including spaces). | ||
| + | |||
| + | |||
| + | ==== Table: tag ==== | ||
| + | |||
| + | ^Column ^ Type ^ Key ^ Function ^ | ||
| + | |tag_pk | | Primary Key | | | ||
| + | |tag | varchar(32) | Unique | The tag text | | ||
| + | |tag_ns_fk | | Foreign Key | The namespace the tag is in| | ||
| + | |tag_desc | text | | Description of what tag means | | ||
| + | |||
| + | |||
| + | ===== Namespace Groups and Permissions ===== | ||
| + | Tag permissions are assigned to tag namespaces, not individual tags. | ||
| + | Each namespace can allow access by 0 - n groups. Each group has their own permission level set by the namespace admin. If a user is in multiple groups, their permission level is set to the lowest level they are granted in the groups. | ||
| + | |||
| + | ==== Table: tag_ns_group ==== | ||
| + | |||
| + | |||
| + | ^Column ^ Type ^ Function ^ | ||
| + | |tag_ns_group_pk | | Primary Key | | ||
| + | |tag_ns_fk | | Foreign key to tag_ns_pk| | ||
| + | |group_fk | | Foreign key to group_pk| | ||
| + | |tag_ns_perm | int | Permission the group has in this tag namespace; 0=none, 1=read only, 2=read/write, 3=admin| | ||
| + | |||
| + | >>Vincent: what's difference of 'tag_ns_group_perm'(group_fk Function) and 'tag_ns_perm'(column of table tag_ns_grp)? | ||
| + | >>Bob: mention of tag_ns_group_perm was left over from a previous version. I've removed it. | ||
| + | |||
| + | "None" means NO access. A permission level of "none" can be used to specifically disallow usage by a group. For example, there may be 5 groups that are members of this namespace, but you want to specifically disallow a couple of users for bad behavior. Just have a user with create group privileges create a group with those couple of users in it, and assign that group the permissions "none". This way those users will have no privileges in the namespace even though they are members of another group that does have access. | ||
| + | |||
| + | In this case "read only" means that this group has access to anything that does not modify the tag. For example, they can search on tags, and use them as report filters. | ||
| + | |||
| + | "read/write" means that you can create new tags in this namespace. | ||
| + | |||
| + | "admin" permission allows you to change namespace and tag names. For example, one might want to correct spelling in a tag. Since items are tagged by the tag_fk and not the tag name, any changes in tag (or namespace) names will take effect immediately. | ||
| + | |||
| + | ===== File Tag ===== | ||
| + | All the above describes what defines a tag and what visibility it has to the user. The tags_file associates a tag with a physical file. | ||
| + | |||
| + | ==== Table: tag_file ==== | ||
| + | |||
| + | ^Column ^ Type ^ Key ^ Function ^ | ||
| + | |tag_file_pk | | Primary Key | | | ||
| + | |tag_fk | |Foreign Key | | | ||
| + | |pfile_fk | | Foreign Key | The namespace the tag is in| | ||
| + | |tag_file_date | date | | Date tagged to file | | ||
| + | |tag_file_text | text | | User supplied text | | ||
| + | |||
| + | |||
| + | ==== Future Possibilities ==== | ||
| + | |||
| + | - **Buckets setting tags** Agents need the ability to tags files. For example, one might want to have a bucket 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. | ||
| + | - **Buckets using tags** Tags could potentially be used as criteria for buckets. In other words a bucket script could query tags and use that as bucket criteria. However, this may not always be a good idea since tags are dynamic and bucket results are static. | ||
| + | - **Tagging a bucket** would work the same as tagging files, except there would be no cascading tagging. | ||
| + | |||
| + | |||
| + | ===== Testing ===== | ||
| + | [[tagtest]] | ||
| - | ==== Design points ==== | ||
| - | - **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. | ||
| - | - **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. | ||
| - | - **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. | ||
