I think this is something you've mentioned before, but just wanted to keep it on the agenda that there's a real need for better tools to allow us to safely archive and remove individual projects from an existing Shotgun instance, so that we can carry on using it with new shows.
Date
Votes
13 comments
-
Mike Romey Yes, Yes, Yes. We have close to 70 projects inisde of shotgun and have yet to come up with a suitable archiving method. I feel like having this many project inside of SG leads to some sluggishness but can't confirm. Reagrdless we really need an alternate method for retiring project that are intended to be archived and not necessarily retired/deleted.
-
KP We're exploring this with our developers now to see what the options are. There are a lot of variables in this request and we need to be able to handle them all in order to add this functionality. Some questions for you regarding this so we can understand the most important aspects of this:
- What are your main reasons for needing to archive Projects from Shotgun?
- Would you expect to be able to re-import the data into Shotgun from the export? (this could be complicated, as you mentioned, with differing versions of Shotgun)
- Aside from Shotgun, what alternative program might you want to have access to the data in?
- Do you have an expected format for the export?
- What are the primary reasons you anticipate you would want to access the archived Project again?
cheers,kp
-
Mike Romey Trying to add a comment but it keep getting bumpped. Wonder if the forum is broken.
-
Mike Romey What are your main reasons for needing to archive Projects from Shotgun?
We need to take existing project and retire them. We have nearly 90 project inside of SG and the number of projects are constantly growing. The problem with the current retirement scenario is that all removed items get retired. Ideally we would like the ability to retire entries in two fashions. The first would retire elements with a deletion category and the second would retire elements with an archive category. This way when we are reviewing retired elements we can filter the retired elements by deleted or archived. Up till this functionality all existing items inside of retired are considered deleted items. Then any place you have a delete functionality you would want to match with an archive functionality. The archive functionality should only be permission to Admin. This functionality should be followed up with a change to the retirement UI. You would need the ability to only display the deleted items , just like the current UI, and another UI that filters only the archived items.
Would you expect to be able to re-import the data into Shotgun from the export? (this could be complicated, as you mentioned, with differing versions of Shotgun)
Yes. If you continue to build upon the retirement paradigm this shouldn't be a big deal. My only possible request would be to possibly offer a rename option for the archive. We use 3 characters to define the name of a project. Example would be "fng" would be for Fringe. If in the future we may needed to use "fng" for a new project but had to unretired "fng" it would be nice to rename "fng" initially when retiring/archiving with a new name like "archive_fng" so existing tools don't get disrupted by the de-archived project.
Aside from Shotgun, what alternative program might you want to have access to the data in?
The data would only need to be accessed from SG. It seems that your asking if we would need the ability to Export the Shotgun data to another Database. Possibly but that is not the heart of our archiving needs. We just need a smart way to deliniate between deleted items and archived items in the retired pages.
Do you have an expected format for the export?
The data would only need to conform to SG if we wer archiving a project. If we were exporting a project out of SG then yes another format would need to be devised. But at the molment that is not the heart of our request.
What are the primary reasons you anticipate you would want to access the archived Project again?
The primary reason for archiving would be to de-clutter SG. The primary reason for de-archiving would be to add to the project database for overages or a second round of production at a later point in time. For long format production the idea of a re-occuring production means a new episode and generally speaking a new project. For us we do so much short format and episodic work that sometime we have to re-uses a callup code or we may want to add new episodes to and exisiting callup code. Having the ability to offline a project and then bring it back online is the heart of our request. The current retired elements doesn't deliniate between manager based deletions and archiving. -
Pliny (John Eremic) I don't feel the need to actually delete information from the server, but I would like to more efficiently hide projects with certain statuses.
Already, having just imported about 30 of our latest projects into SG, I am finding the popup menu that hides/unhides projects ("Project X of X" in the left nav) itself to be unwieldy. I can only imagine what it will look like in a few months.
I would want that popup to only display projects with certain statuses (e.g. not display projects "closed", "on hold", etc.). But since we will be using custom statuses, I would want it to be admin-configurable _which_ statuses are hidden and revealed in the popup menu.
-
Mike Romey Pliny
Not sure if your using 1.8, but we recently upgraded. Regarding this subject matter, if you impliment the person affiliations and permissions the nav bar is considerably more organized. The person/project affiliation allows us to limit the projects a specific artist or manager see in the nav bar. It serves a few purposes. The first is for security. This way artist and managers do not have access to projects they are not working on. The second valuable purpose this functionality offers is that it allows us to optimize what each user see's in their nav bar. I have a few minor suggestions to the person / project affiliation pages.
1. We now have to maintain 2 person/project affiliation groups. One from the dashboard so users can see specified projects and another from groups so those same users get e-mail from the project. It would be nice to consolidate so managers are not required to maintain both groups. I know our producers and I know I will get an e-mail saying "hey, Shotgun notes is broken I can't work!" or "hey, Shotgun is broken I can't see my project!" When in fact a producer has forgotten to administer these two groups and add that user user to the corresponding group or project affiliations. Consolidation would relieve confusion.
2. The Person/Project affiliation has a start date and end date. It would be really awsome if when the end date was met that they were removed from the group. I get requests all the time asking me to remove somebody from the group because they are not longer activily working on the project and are not interested in receiving the spam of e-mails associated to the group. If the end date was met and the user was purged from the affiliation that would relieve the auto e-mail notifications as well as insure security for our projects after an employee moves on to a different project.
Regardless of these new additions we now have about 150 projects. So it's really important to start thinking about archiving projects. We need a better solution than simply retiring a project. Like I have stated earlier, we need a delineation between retired elements that were purposed for deletion and retired elements delineated for archiving.
-Romey
-Romey
-
Pliny (John Eremic) Romey,
I'm on the hosted version hence running 1.8.5. The issue for me is that I deal with a large volume of jobs -- some large production + DI jobs, other very small dailies jobs. So most staff will still need _scores_ of projects exposed to them at any given time. At very least, producers and admin already are looking at 30 or so jobs, and that will only grow over time. So handling this via stricter permissions is not my solution. I need to be able to set a job to "closed" or "inactive" and have it disappear temporarily from the blue nav.
-
Mike Romey Pliny,
I hear ya. I had made the same request to Don regarding the Nav Bar a few months back. It would certainly be nice to be able to display all affiliated projects by status in the Nav bar. This way if you are Admin or a Manager or even an Artist with a few dozen or hundred projects to manage you have the capacity to manage them by status. So if you have a status set to closed or archived for some specified projects for review you don't have to dig through the nav bar and every dashboard to get to the info you need.
-Romey
-Romey
-
Andy Geers With all these exciting new-fangled big feature requests floating about in the forum, can I just put in my two cents and say that though this feature request (being able to remove projects from the database and free up the associated disk space) is really boring in comparison, it is far and away our highest priority feature request. We could live without most other new features you might consider writing if only we could have this one.
Also, it occurs to me that another feature request floating about (being able to specify a separate directory per project for storage of files/thumbnails/etc.) could be used to solve this issue - as long as each project has it's own directory, it's relatively easy to backup and then delete all of the files for that project. All that's then lacking is an easy way to export the data itself from all of the tables before permanently deleting.
-
Warwick Hewett We have been looking into archiving completed projects into excel, as a back-up and to match how we have historically archived out work, we don't currently need to delete the data from the SG server. We can export assets, shots, tasks, versions and playlists fairly nicely but there are a few niggles.
1. a simple way to export all the thumbnails so they can be matched to their relevant shot, we can download images from the browser and link them, but to see them would require lots importing and formatting of the document.
2. could we have a export to archive "button", that would make one excel file with tabs for all the different areas such as shots and versions
Or are we approaching this the wrong way, if there is a way??
Any help or suggestions appreciated
Warwick
-
Ben Hadden @Warwick
It's on our roadmap to support exporting Thumbnail images into Excel. We're also planning to support better formatting (of numbers, colors, etc) as well as grouping the data as you have it on a page.
We hadn't considered exporting an entire Project's worth of data, but I like your idea for exporting all entities and organizing them as Worksheets in the Workbook. What does everyone else think about that? Would it be useful?
-
Cody Charfauros Absolutely, I would love to be able to export the full project to a CSV or other neutral format.
Excited about the ability export the Thumbnail as well!
-
Juanmaria Garcia Exporting to an Excel sheet would be good for us also. Our main concern is having the data accessible for future projects that might continue or resemble finished ones. We would like a lot to have a format that almost anyone could access in the mean time, and also to be able to revive an old project or use it as a template for a new one.
In some circumstances, like interrupting the SG subscription for a certain period of time, that would make us feel more comfortable, and less "captive".
Thanks a lot
Please sign in to leave a comment.