Community
Participate
Working Groups
It should be possible to export and import a local task using drag&drop, context menu and through file's menu
I suggest creating a xml.zip file with two type of xmls inside: one type describes tasks (mini version of a tasklist.xml) another type describes the context of a single task that is described in a first type of xml(so there can be many of these xmls).
The above described zip file is supposed to be a transfer object in task export/import operations.
Usually when you drag multiple selected objects they transfered as multiple, so it is confusing to archive them all together when doing drag and drop. Import/export wizard is probably different story, as long as it would allow to choose which tasks should be imported (as opposed to blindly import them all)
(In reply to comment #3) > Usually when you drag multiple selected objects they transfered as multiple, so > it is confusing to archive them all together when doing drag and drop. Yes, you are right. One file per task is better, we'll be able to naturally select only these tasks that we are interested in. I will create a single archive for each task, but I still want to keep these xmls separate (tasklist, context, in case of a repository task - repositories) - it will dramatically decrease a number of changes.
I think it is ok to have multiple files in the archive. Also, it seems like you are also need repository configuration in there, just in case repository does not exist when task is imported.
Yes, do it something like this: - mylyn-data-12345.xml.zip - tasklist-fragment.xml (task/query xml) - repositories-fragment.xml (repo you needed to externalize) - contexts (directory) - http%3A...zip (context file) This way you are mirroring the current structure in these transfer/import fragments.
-1 for any directories in archives
Created attachment 75866 [details] Task exporting/importing core - InteractionContextExternalizer: extracted writeContext() functionality - InteractionContextManager: added loadContext() method to load context from external files and added importContext() that adds context to the system and activates it. saveContext()&activateContext() doesn't work, since they change the original context. - SaxContextReader: fixed reading context from a file where there is more than one ZipEntry. Also have fixed ContextExternalizerTest. - TaskRepositoriesExternalizer: renamed writeRepositoriesToZipEntry() to writeRepositories(), also fixed QueryExportImportTest - Added TaskExportImportTest and updated AllTasksTests TaskListWriter: - added contextExternalizer - encapsulated TaskList Document creation and TaskList root in a single method (to reuse in writeTask()) - added writeTask and readTask to read/write task + context. Currently, task's child tasks are not read, this will be fixed in next patch (if needed? How do I create a child task?). Also, context is not saved under 'contexts' folder, since one file can contain only one context right now.
Created attachment 75867 [details] mylyn/context/zip
Either myself or Mik will have a look at this early next week Jevgeni. I think we should initially ignore subtasks, Mik?
Created attachment 76148 [details] Task exporting/importing core + d&d This patch includes all previous changes plus: Separated reading and adding to the taskList process. These required me to add a categoryHandle property in AbstractTask, which is populated during reading and used during writing. After that, I have removed the dependency on taskList when reading the Task from the file. This patch also contains D&D support for tasks. If task doesn't exists - it is inserted to the task list. If it does, user confirms that he wants to override this task's context.
Created attachment 76149 [details] mylyn/context/zip
Created attachment 76150 [details] Task exporting/import core tests Tests that are covering previous patch (export-import-tasks-core_1_1.txt)
Jevgeni, I haven't had a chance to review your latest patches. Depending on how my Friday morning goes I may get a chance but if not it won't be until Monday. Let me know if this is blocking you. Note that I've committed changes to QueryExportImportTest to fix subsequent failing tests in the test suite. QueryExportImportTest was a) setting synchronization manager to asynchronous and b) replacing the tasklist externalizers with mock externalizer but never resetting them back.
Sorry for the delay Jevgeni, this is good work! My only concern here is addition of categoryHandle to AbstractTask. My initial thinking on this is that we should make createCategoryElement work similar to createQueryElement in the sense that it contains its members. Then deprecate AbstractTask.getParentContainers() all together moving this to the TaskList. Then as part of import export include any necessary parent Category nodes with the task id contained minus those that aren't being exported. This is a rough idea and we will obviously have migration and api issues but I want to your feedback on this. Pointers: - Before submitting a patch, try to ensure Mylyn AllTests passes. This is tricky as currently there are 4 tests that fail when run as part of the suite but pass when run individually. Ideally we want this test suite to always pass so this won't be such a trick in the near future. Changes I made to get all tests passing (except for those pesky 4): - Updated context externalization tests so that they pass. Once patch is applied these tests were failing since the contained context must have a proper handle. - TaskListWriter.readTaskList updated to only add task to tasklist if delegating task externalizer returns a non-null value
Created attachment 77313 [details] Patch with some alterations Alterations minus reqd binarys for tests to pass. Updated to avoid a collision with TaskListDropAdapter.
Created attachment 77945 [details] Task export action for task list view If one task is selected, then File dialog is used, otherwise user will specify the directory, there to save selected tasks. This patch depends on the previous "Task exporting/importing core" patch. The last one, as I understand, previous is not yet applied so in order to test this, both patches should be used.
Created attachment 77946 [details] mylyn/context/zip
Rob, I think category can be included to the exported file. Otherwise, if mylyn sees that there are no such category, when importing the task, then such category can be created (category name is known from the task tag). However, if you were planning to make heavier this concept and introduce new attributes, then I prefer going the first way right now.
Rob: please review.
Patches applied ip log updated. I think we'll need to export the repositories.xml along with the other data exported as part of task export since the repository task's repository may not exists in the target (much like query import/export). Added deprecated note to get/setCategoryHandle() methods on AbstractTask.
Created attachment 78563 [details] Task import action for task list view TaskList is refreshed on import. Imported task is not activated.
Created attachment 78564 [details] mylyn/context/zip
Jevgeni: patch applied, some quick manual testing done, and things are looking good! I will iterate on the UI for this (e.g. consider making a sub-menu in the Task List and/or a view menu) and then report back. Could you outline anything else that you think needs to be done on this for next week's 2.1 release?
(In reply to comment #24) > Jevgeni: patch applied, some quick manual testing done, and things are looking > good! I will iterate on the UI for this (e.g. consider making a sub-menu in > the Task List and/or a view menu) and then report back. Could you outline > anything else that you think needs to be done on this for next week's 2.1 > release? > Thanks! According to my notes, I have to add an icon to export actions and implement saving a context before exporting it (for active tasks, if the context was changed, then the old one is currently used). The rest of activities are code refactorings. Could I miss something?
*** Bug 204509 has been marked as a duplicate of this bug. ***
I've done the following: * Grouped these 4 actions and the 2 duplicate actions into an Operations menu. The name is not ideal, but these need to be nested in a submenu since they are infrequently used, the word File is not appropriate, and calling it something like "Task Operations" is not suitable because other creations are not there. I made enablement toggle, not visibility, so it that the user know what the full set of operations is (matches the our policy for not hiding actions in submenus). * Added icons for export and did additional clean-up of the actions. Jevgeni: I removed definitionId (org.eclipse.ui.query.clone) from the query clone action. Was this used for anything?
Created attachment 79224 [details] mylyn/context/zip
Mik: no, definitionId was not used, so it is ok to delete it.
*** Bug 196031 has been marked as a duplicate of this bug. ***
