| | 9 | |
| | 10 | I was thinking to implement this plugin based on the FlatFileParser used by most other import plugins. The plugin should be usable both with and without a configuration. If used without a configuration it works like this: |
| | 11 | |
| | 12 | 1. The user selects a file and sets the regular expressions to parse it, possible with help from the "Test with file" function. |
| | 13 | 2. The plugin parses the file to get the data headers. Each header can now be mapped to an annotation type. One column should be mapped to either the name or the external ID of the item to annotate. The plugin should try to match the header names with annotation types to provide a default mapping. |
| | 14 | |
| | 15 | '''Multiple valued annotations''': Either map two or more columns to the same annotation type or use more than one row for items with multiple annotation values. |
| | 16 | |
| | 17 | '''Finding the items''': We must use the name or external ID to find items. Since neither has to be unique there is a possibility of more than one match. This could be an error condition or we could annotate all items. If no item is found it could be an error condition or we could just ignore it. There should also be options to specify which items to search: owned, shared, in active project, etc. |
| | 18 | |
| | 19 | '''Error handling''': Invalid annotation values could be considered an error condition or ignored. |
| | 20 | |
| | 21 | '''Replace vs. add or updat'''e: There should be an option to specify if annotations that can take multiple values should be replaced or if we should just add new values. If the annotation can only take a single value there should be an option if the value should be updated or not. |
| | 22 | |
| | 23 | '''Using with configuration''': A configuration should store regular expressions and mappings. The user has to select a file and specify other options. It should be possible to override the regular expressions and mappings. |
