| 3 | | * Add a new table for storing datetime values and a subclass to `ParameterValues` to handle it. |
| 4 | | * Add a new option to the `Type` enumeration. |
| 5 | | * Update the gui so that it is possible to add datetime values |
| 6 | | * Update the query api so that it is possible to search for datetime values |
| 7 | | * There are probably some effects also on the plug-in api since the `Type` enumeration and `ParameterValues` class are used by plug-in parameters as well. I'll have to investigate the effect and maybe add a specific ticket for adding datetime support to the plug-in system if the work required is substantial. |
| 8 | | * There may be similar effects on "extendable" classes (eg. reporters, users and raw data). |
| 9 | | * Check and update documentation |
| 10 | | * More...? |
| | 3 | 1. Add a new table for storing datetime values and a subclass to `ParameterValues` to handle it. |
| | 4 | 2. Add a new option to the `Type` enumeration. |
| | 5 | 3. Update the gui so that it is possible to add datetime values |
| | 6 | 4. Update the query api so that it is possible to search for datetime values |
| | 7 | 5. There are probably some effects also on the plug-in api since the `Type` enumeration and `ParameterValues` class are used by plug-in parameters as well. I'll have to investigate the effect and maybe add a specific ticket for adding datetime support to the plug-in system if the work required is substantial. |
| | 8 | 6. There may be similar effects on "extendable" classes (eg. reporters, users and raw data). |
| | 9 | 7. Check and update documentation |
| | 10 | 8. More...? |
