Projects:Tags/Specifications
 | This document is still a work in progress. It may contain inaccuracies or errors. |
Contents |
Tags - Functional Specifications
Overview
Purpose
The purpose of the tags in Openbravo is to radically improve the user experience by allowing users to label elements in the system and subsequently browse or search data based on tags.
Prior to tags, a similar capability could be implemented using projects (i.e. all transactions can refer to a project and it is possible to retrieve all the transactions that have been associated to any given project). Projects, however, have accounting implications and are typically managed by a Financial Controller.
Tags provide the freedom to any user to build an arbitrary taxonomy of the transactions in the system.
In addition it will be possible to navigate from a single window to all the elements, wherever they are, containing some tags.
For example:
- An Administrative Assistant reviewing expense report could tag expense lines for which she needs clarification and then walk into a meeting and easily retrieves the data that need review.
- A Customer Support Representative could tag hot customers and easily retrieve any transaction that is related to them.
This development should be focused on simplicity: it should be simple to edit tags and it should be simple to use them.
Scope
This functionality will apply to the whole application: any element can be tagged.
For example a group of orders could be tagged as "Sales2007" and the same tag could be used for a bunch of invoices.
Constraints
- Tags are text strings without blank space on them.
- Blank spaces are used as tags separator: "Sales 2007" would be parsed as two tags ("Sales" and "2007").
- Tags are case insensitive: "SALES", "Sales" and "SAles" are the same tag.
- Filtering tags doesn't allow wildcards: to filter "Sales2007" and "Purchases2007" the filter clause should be "Sales2007 Purchases2007" but "%2007" would not be valid.
Glossary
- Tag: Tags are text labels that can be associated to any element in Openbravo.
- Element: An element is any record in any tab of the application. For example a business partner, an invoice or an order line are elements.
- Public/Private tags: A tag defined as private is only seen by the user who set it and public one is shared among all the application users.
Functional Requirements
Use cases
The interactions with tags are:
View Element Tags
It is possible to see which tags have currently associated any element. The tags that are seen here are all the public ones for this element plus the user's private ones. This view is accessible both in relation and edition mode, in relation mode common tags for the selected elements should be displayed in a different way that those that are not for all the elements.
Edit Element Tags
From any element it is possible to add/modify/delete its tags. This modifications should be easily set as public or private. When this editions are performed from the relation view the modification are applied to all the selected elements.
Filter by Tags
In addition to the current tab filters, tag filters will be included. This filter is summed to the previous one. For example: a filter for those invoices which document number starts by "555" (555% typical filter) and tagged with "Sales2007" can be used.
Browse Tags
Apart of the tab filter for tags, tags are browsable using a common filter that will show all the elements containing a user given set of tags wherever the elements are in.
Technical Requirements
User Interface
According with the defined Use cases these are the elements designed for the tags management:
Tag button in toolbar
A new button appears in toolbar that will open the Edition Interface. This button is accessible in edition and relation modes of every tab.
Edition Interface
A single interface is designed for View Element Tags and Edit Element Tags use cases. This interface shows two text boxes, one for public and another one for private tags, where the defined tags appear and it is possible to edit, add news and remove existing ones.
When it is invoked from the relation view in these two boxes appear the common tags for the selected items, and in addition a non-editable text appears with the tags that are contained in some elements but no in all of them. When the text boxes are edited the tags there are applied to all the selected elements.
To be defined
- This interface can be implemented as a popup or as a floating div. The second one is more visual and should be performed in case its overhead is not too big.
- Ideally, tag suggestion could be used, this means: while text is inserted in the box already used tags starting with the written text should appear making possible to click on them to add to the tag list.
Filter
The Filter by Tags use case is implemented in the already existing filter button. A new tab is added to this filter to filter by tags. This tab contains a text box where tags are added.
To be defined
- A list of existing tags can be displayed in order to make easier the selection of tags.
- In case the tag suggestion is implemented it could be used here.
Tag browser
Browse Tags is implemented by a browser accessible via left menu. It is a pop-up similar to the one displayed clicking the "linked items" button.
When it appears its filter is populated by default with the tags in the current element.
The contents of the browser are:
- Filter box: a text-box containing all the tags the user wants to filter by.
- List of existing tags: A list of all the existing tags (all the public and the user's private ones), the clicked tags are added to the filter box.
- Search button: when it is clicked the tags in the filter box are applied.
- List of elements: Once the filter is applied a list of elements containing the selected tags is shown. This list is grouped by element type.
To be defined
- The list of elements could show also all the tags contained in every element making possible to filter by them just clicking on them.
- If this list of tags is implemented a button next to each of them could allow to delete them from the element.
- This browser could be used too in order to edit/remove for all the elements one tag.
Database implementation
Tags are implemented in a single database table (C_Tag) with the following fields:
| Name | Null | Type | Description |
|---|---|---|---|
| C_TAG_ID | NOT NULL | NUMBER(10) | Tag identifier |
| AD_CLIENT_ID | NOT NULL | NUMBER(10) | Audit field |
| AD_ORG_ID | NOT NULL | NUMBER(10) | Audit field |
| ISACTIVE | NOT NULL | CHAR(1) | Whether the tag is active |
| CREATED | NOT NULL | DATE | Audit field |
| CREATEDBY | NOT NULL | NUMBER(10) | Audit field |
| UPDATED | NOT NULL | DATE | Audit field |
| UPDATEDBY | NOT NULL | NUMBER(10) | Audit field |
| AD_TABLE_ID | NOT NULL | NUMBER(10) | The table where the element is in |
| RECORD_ID | NOT NULL | NUMBER(10) | Primary key for the element |
| TAG | NOT NULL | VARCHAR2(20) | Tag text |
| AD_USER_ID | NOT NULL | NUMBER(10) | The user who created the tag |
| ISPUBLIC | NOT NULL | CHAR(1) | Whether the tag is public or not |
Known issues
- Due the database implementation and the focus on simplicity of this development, tags are only valid for tables with a single field as primary key (the most in Openbravo), those with more than one primary key fields will not be able to have tags.
Open Issues for Discussion
- PJU: Is VARCHAR2(20) adequate for tags? Shouldn't it be VARCHAR2(40) or VARCHAR2(80) instead?
- PJU: Rather than editing tags in a pop-up, I think it would be more effective to edit them directly in the main window. An ideal UI would be to have a region at the bottom of the screen that lists, in two separate rows, the public and the privata tags. The lists would appear as static text but when the user moves the focus on them, they should become editable fields. You can see an example of this behavior in Google Documents, when you see a folder: the folder name and description appear as static labels but as soon as the pointer moves on them, they become editable fields.
- ALO: We discussed about this when we were defining tags and we decided not to have it in the main window, but clicking a button in the tab in order not to give tags an excessive importance.
- PJU: In order to facilitate adding the same tag to multiple records, it would be desirable that the field where tags are entered auto-completes and auto-suggest tags. For example, when the user types 'Sa', the system adds a drop down that lists all existing tags that begin with 'Sa', like 'Sales2007' and 'SasS'. You can seen an example of this behavior at Issues Done (www.issuesdone.com).
- ALO: This is what I called tag suggestion in the to be defined section, in fact, I think this should be implemented.
- PJU: In addition to using tags as additional filters in the search screen, I think it would be very useful to have a region at the bottom of the navigation pane (the left part of the screen where the menu is) where the user could select the tags that he wants to filter by. This tags should be automatically applied as filters to the current screen and should persist when the user navigates to another screen. This way it is going to be possible to browse different transactions and view only elements that match a particular tag. There should be an easy way to reset this tag filter. You can seen an example of this behavior at Issues Done (www.issuesdone.com).