|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Tim Eck - 24/Dec/04 02:25 PM
I'd be happy if there was at least a documented/available method for restoring single projects (ie. it could be some sort of manual process and/or unsupported script)
Hi Asgeir,
Thanks for the update. Please note that we do have issues with over 100 votes at the moment, and we would like to address them first. Just for information, if you need to 'move' projects between JIRA installations one way of doing this would be to find all issues of a project in teh Issue Navigator, add as many columns as needed to your Issue Navigator list, export to Excel, save the result as a CSV and tehn use JIRA's CSV importer: Ability to customise columns exported to Excel has been implemented in JIRA 3.2. Thanks, How do you suggest we migrate the userbase in such procedure?
You are right, the users and groups will not be exported as part of the CSV. At the moment the only thing I can suggest is creating scripts that copy the information from one database to another or from the XML export. We do have Jelly tags that can be used to create users and groups, and they might be some help:
http://www.atlassian.com/software/jira/docs/latest/jelly.html 
Your suggestion also loses attachments and task linking. That's a major loss. I'm looking at that now as I've been required to move our 1000 task project to a different Jira instance but can't afford to lose these items.
Dear JIRA support,
we would like to force this issue, Kind regards, We also need these feature.
We deleted all issue from last year to optimise JIRA usage. Thanks, Hi JIRA support
We need this feature too. I'm in the process of migrating projects from Fogbugz to JIRA which is a taks your FogBugz importer handles very well. Unfortunately, we do not like the "big bang" method - rather we want to migrate single projects when we find it suitable. One way of doing this is to migrate a project to an empty JIRA database, export it to Excel, save it as a CSV-file and import it to the real JIRA database. However, if you do this, you loose attachments, issue links and comments. The first two I can fix by hand but it is a no-go to loose all the comments. Much of the information in an issue is contained in the comments - so this is where I'm stucked. Regards We too have the need of exporting a single project with all attachments, comments etc. So we are capable to put import a project on a different instance of Jira (moving from our company installation to one of our customer(s))
Regards, Ray Hi!
I'm on my vacation and will be back at the office on July 30th, 2006. If you got this email after sending a message to an email list I've subscribed to, please accept my apologies on behalf of the autoresponse-system. Thank you, sulka we too need this to move projects between different jira instances
A recent post to the forum (by Nick Menere) said:
Unfortunately, there is no way to backup on a project by project basis. It is extremely technically difficult due to the configurations associated with a project and how they could manipulated between the back up and restore. I'm not sure I understand all of the technical difficulties presented, if you avoid storing or restoring the project definition itself (i.e. schemes associated with the project). Just import the issues as is. The steps would be: Then have potential bells & whistles like: Hi!
I'm on my vacation and will be back at the office on July 30th, 2006. If you got this email after sending a message to an email list I've subscribed to, please accept my apologies on behalf of the autoresponse-system. Thank you, sulka Neal,
Though what happens if steps in a Workflow have been deleted (or an entire workflow has been deleted). If a project that relied on this was imported, what would it use? Cheers, I did think of workflows etc. - I just don't see it being such a big deal. The issue's state in a workflow is not saved - just its status. So you only have to worry about statuses that don't fit into the current workflow.
Say you have an issue whose status is "Re-opened", and there is no way to get to that status using the new workflow for the project. So, you prompt the user to pick a status. You already do that when you associate a workflow with a project, so you already have that logic. Other schemes are also no issue. Because the key to my point is that you don't have to save and restore the schemes that were once associated with the project. The admin would have to be responsible for setting those up again when the project is re-created. All you need to do is import the issues. And, again, same goes for custom fields. JIRA is already smart enough to handle custom fields being added and removed. I think you're thinking of doing too much which is to somehow preserve all the proect info and schemes which might be shared, when most of the users waiting for this issue would be happy with a simple import/export of the issues themselves. Am I wrong? Personally, I agree with Neal. I'm most interested in this feature as an "archive" function. So that we clean up the database by removing old, inactive projects. If we needed to restore a project, we most likely would be doing it for historical purposes. Thus, we would just need to see the data and we wouldn't be changing it (e.g. stepping it through workflows, making comments, etc...).
I, of course, don't have intimate knowledge of the internals of Jira. However, the only tricky thing I can think of is that the restore function may need to re-create users. Neal, Erik,
We do actually store the workflow state of each issue. I think the best way to do it would be store a copy of the workflow with the project and when importing, do a workflow migration from that to a current one if needed. But then there are other issues with Issue securities and not to mention Issue Types. It would get real messy. It is almost like you would need to store a deep copy of all the schemes and then perform a migration for each one on import.... Could get real dificult as I don't think the code would handle deleted Statuses, Issue Types and other things that well... I don't see any part of this as optional, this is all to get it into a working state. As a first step I would be happy with something that would allow you to export issues and import them into a project on another database. It could work a bit like the move issue functionality. There would need to be a solution for missing / deleted users though. M
Most of our projects use the default configuration (workflow, permissions etc.) so this would work fine for us. My vision of this would be essentially the same as:
So you end up with all workflows, permissions, status, users, etc but only one project. Thus anyone could create a new Jira instance, import this backup and only have one project but it's ready to go. Importing back in to an existing Jira instance with other projects would obviously require some merging, adding or re-mapping of missing statuses, users, workflows, etc. Dear Atlassian engineering,
The whole concept of migrating projects is clearly an important piece of functionality that is crutial to an enterprise setting. As an example, "we" currently have 6 production instances with 3000+ users and 500+ projects - this is only going to grow. We have split our existing instances a number of times already which involved XML exports/imports, duplicating DBs, and deleting projects manually - a very time consuming and manual process. At present there is no way to migrate a project from one instance to another and in a sense we are stuck with what we have despite frequent requests to move or archive off projects. Also as DBs grow Jira is naturally going to slowly grind to a halt so some mechanism of selectively migrating, depracating projects is necessary. The problems involved in migration have been highlighted in the comments above - true, one would have to have a mechansim to do a "deep" migration of a project and all its dependent schemes/settings and validate the integrity of a migration - this is not easy. Still the problem remains and is a crutial one to crack. So, Jira engineers, you need to come up with a workable solution to this problem to further improve this fine product. In the first instance, would it not be possible to at least identify the moving parts and allow for migrating them in some fashion and when importing do an integrity check so as to assign the requisite schemes/configs ? I understand that features like custom issue types map globally to unique IDs and are picked up by issue type schemes so this would necessitate a remapping for migrated projects - that's a complexity that would need to be delt with. Same would presumably need to be done for workflows. Perhaps to do this cleanly would require a redesign of Jira's DB schemas - still the migration of projects issue is not going to go away and needs to be addressed in a sensible manner. So, please, put this feature request in the pipeline as high priority - it will make life a lot easier for most of your customers. Cheers, Bernard OK - well I can see there is a need for this. Again, I just don't see this as being a monumental effort. When you import the file the contains the issues, you do a pre-pass to identify things like missing users, statuses etc. - whatever you think could pose a problem - and you can even force the importer to set them all up first. For example, I import issues assigned to "joe" with a status of "Verified". The pre-pass says "Sorry, 5 issues involve unknown user 'joe' ". So, if the user "joe" is in the assignment history, or reporter, or assignee of the imported issue, you'll have to address that first by adding the user. Put the onus on the administrator and not on trying to figure out how to fix all the data coming in. Same for any situation - unknown status etc. I'm not sure what you mean by "We do actually store the workflow state of each issue." but it doesn't matter anyway. Any situation that you can't resolve is the admin's problem to sort out. In a simple case of archiving and restoring or migrating, it'll satisfy most of the people waiting for this feature. Once it's in place you can slowly add additional features like auto-migrating to a specified status like when you associate a new workflow with a project or import issues via CSV. All the smarts are already there.
Besides, there are many ways to get issues into the same state - by changing the workflow of a project, by deleting a user with no reported or assigned issues, etc. So the integrity issue isn't new. I think one of your fine developers could probably get it 75% done on just one Fed-ex day I would like to add my voice as well. I agree with Neal. We need at least something. Just exporting/importing the issues and let the admin sort out the details, while not ideal, would be a step in the right direction. It is great that you are concerned with getting every last little detail taken care of in every possible scenario, but I'm wondering how many out there are using all of the extra features and customizations you are trying to accomodate. If you release a feature that doesn't have all of the obscure scenarios taken care of, then at least some of us can do what we need to. If such a feature were released, but it didn't work for my exact situation I would be disappointed, yes, but I would be no worse off than today where I have no export/import functionality whatsoever. With such a feature release at least some of us would be able to use it. With no such feature release, NO one can use it.
I think Neal's got the right idea. Give us at least something, even if the administrator has to sort out the details and deal with the exceptions. Hear, hear!
 An incremental approach to this is definitely a way to go. Hi!
I'm on my vacation and will be back at the office on July 30th, 2006. If you got this email after sending a message to an email list I've subscribed to, please accept my apologies on behalf of the autoresponse-system. Thank you, sulka | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
New Feature
Open
Major
Import / Export (backup / restore) individual projects
