See items information of a file

itemToFile

Have you ever wished to access item and BOM information right from your file without the need to actually go to it? Here is a Data Standard sample that solves this problem. It’s a little tab that shows item information with the according item BOM of the current selected CAD file.

The technique is somewhat easy. It’s basically one XAML and one PS1 file. While the XAML is straight forward, it’s a grid with properties and a DataGrid for the BOM:

<Grid>
  <Grid.ColumnDefinitions>
    <ColumnDefinition Width="*" />
    <ColumnDefinition Width="*" />
  </Grid.ColumnDefinitions>
  <Grid x:Name="ItemData" VerticalAlignment="Top" Margin="10">
    <Grid.ColumnDefinitions>
      <ColumnDefinition Width="80"/>
      <ColumnDefinition/>
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
      <RowDefinition/>
      <RowDefinition/>
      <RowDefinition/>
      <RowDefinition/>
      <RowDefinition/>
      <RowDefinition/>
    </Grid.RowDefinitions>
    <Label Content="Item"/>
    <TextBox Text="{Binding Item}" Grid.Column="1"/>
    <Label Content="Revision" Grid.Row="1"/>
    <TextBox Text="{Binding Revision}" Grid.Column="1" Grid.Row="1"/>
    <Label Content="Title" Grid.Row="2"/>
    <TextBox Text="{Binding Title}" Grid.Column="1" Grid.Row="2"/>
    <Label Content="Category" Grid.Row="3"/>
    <TextBox Text="{Binding Category}" Grid.Column="1" Grid.Row="3"/>
    <Label Content="State" Grid.Row="4"/>
    <TextBox Text="{Binding State}" Grid.Column="1" Grid.Row="4"/>
  </Grid>
  <Grid Grid.Column="1" Margin="10">
    <DataGrid Name="bomList" AutoGenerateColumns="True" IsReadOnly="True" ColumnWidth="Auto" HorizontalGridLinesBrush="WhiteSmoke" VerticalGridLinesBrush="WhiteSmoke"/>
  </Grid>
</Grid>

The PS1 file is a bit more work. We basically have to collect the item information first and then transform the BOM information into a small list that fits into the DataGrid:

Add-Type @"
public class itemData
{
  public string Item {get;set;}
  public string Revision {get;set;}
  public string Title {get;set;}
  public string Category {get;set;}
  public string State {get;set;}
}
"@

function OnTabContextChanged_Item
{
  $xamlFile = [System.IO.Path]::GetFileName($VaultContext.UserControl.XamlFile)
  if ($VaultContext.SelectedObject.TypeId.SelectionContext -eq "FileMaster" -and $xamlFile -eq "Item.xaml")
  {
    $fileMasterId = $vaultContext.SelectedObject.Id
    $file = $vault.DocumentService.GetLatestFileByMasterId($fileMasterId)
    $items = $vault.ItemService.GetItemsByFileId($file.Id)
    $item = $items[0]
    SetItemData -itemId $item.id
    SetItemBomData -itemId $item.id
  }
}

function SetItemData($itemId)
{
  $properyDefinitions = $vault.PropertyService.GetPropertyDefinitionsByEntityClassId("ITEM")
  $properties = $vault.PropertyService.GetPropertiesByEntityIds("ITEM",$itemId)
  $props = @{}
  foreach ($property in $properties) {
    $propDef = $properyDefinitions | Where-Object { $_.Id -eq $property.PropDefId }
    $props[$propDef.DispName] = $property.Val
  }
  $item = New-Object itemData
  $item.Item = $props["Number"]
  $item.Revision = $props["Revision"]
  $item.Title = $props["Title (Item,CO)"]
  $item.State = $props["State"]
  $item.Category = $props["Category Name"]
  $dsWindow.FindName("ItemData").DataContext = $item
}

function SetItemBomData($itemId)
{
  $BOM = $vault.ItemService.GetItemBOMByItemIdAndDate($itemId, [DateTime]::MinValue, [Autodesk.Connectivity.WebServices.BOMTyp]::Tip, [Autodesk.Connectivity.WebServices.BOMViewEditOptions]::Defaults)
  $assocs = $BOM.ItemAssocArray | Where-Object { $_.ParItemId -eq $itemId }
  $childIds = $assocs | ForEach-Object { $_.CldItemId }
  $properyDefinitions = $vault.PropertyService.GetPropertyDefinitionsByEntityClassId("ITEM")
  $properties = $vault.PropertyService.GetPropertiesByEntityIds("ITEM",$childIds)
  $data = @()
  foreach ($id in $childIds) {
    $props = @{}
    $ppys = $properties | Where-Object { $_.EntityId -eq $id }
    foreach ($property in $ppys) {
      $propDef = $properyDefinitions | Where-Object { $_.Id -eq $property.PropDefId }
      $props[$propDef.DispName] = $property.Val
    }
    $item = New-Object itemData
    $item.Item = $props["Number"]
    $item.Revision = $props["Revision"]
    $item.Title = $props["Title (Item,CO)"]
    $item.State = $props["State"]
    $item.Category = $props["Category Name"]
    $data += $item
  }
  $dsWindow.FindName("bomList").ItemsSource = $data
  $dsDiag.Trace("<< SetItemBomData")
}

As you can see, in the XAML file we bind the TextBoxes to some properties, like Item, Revision, Tile, etc. Usually you would bind such TextBoxes to a Prop[Item].Value or Prop[Revision].Value. Well, by doing so we would just get the values from the selected file, but we want the values from the item linked to the selected file. Now, we can either set the values one by one to the according TextBoxes, from the PowerShell script that runs behind, but in this case I’d like to show you a more elegant way. We basically create in PowerShell our little C# class that we then set as a DataContext to the Grid that contains the TextBoxes. This way, whichever control is inside the Grid, like our TextBoxes, will be bound to the new source of data. So, the Binding now works against our little C# class. So, in the PowerShell we simply populate the properties of the class with values, inject the class as DataContext to the Grid, and let the Binding do the rest. In order to have this working, the attributes of the class must be properties (get;set;).

The DataGrid receives the information in a similar way, but via the ItemsSource. The nice thing about the DataGrind is that with the option AutoGenerateColumns the columns will be automatically generated – less work for us.

The only thing that must be done is to modify the OnTabContextChanged in the default.ps1 and add our function OnTabContextChanged_Item so that our code gets executed whenever a new file gets selected.

If you like to get this sample running on your side, just download the sample from GitHub and follow the instruction.

Enjoy!!

 

Posted in Data Standard, PowerShell, Vault API | Leave a comment

Menu item with Data Standard

blog-20141117

In preparation for my Autodesk University (Las Vegas) session with the topic “Introduction to Data Standard”, I’m creating samples around numbering, advanced dialogs in CAD and Vault, some cool tabs for Vault and also menu items. In the next weeks I will post the samples on this blog. However you are welcome to visit my session at AU and pass by to say hello!

Today, I’m going to talk about menu items. Data Standard offers an easy way to create additional menu items and place your personal custom logic behind. In order to demonstrate how this works, I will create a simple menu item that queues a job in the job queue. Actually, the item on the file context menu will place a PDF job in the job queue for the selected files. It’s pretty simple but it explains the technique behind and for all those of you who love powerJobs – our solution for creating PDF files and more – it’s a good and simple add-on.

In order to create a menu item, we need to do two things:

  • editing the mymenu.mnu
  • creating a little PowerShell script file

The mymenu.mnu is located in the DataStandard\Vault folder and contains all the menu item definitions. It’s a simple text file, so you can edit it with any convenient text editor. At the top of the file you will find text blocks or sections that all start with “item” and then the name of the section. An “item” represents a menu item. So, let’s create a new item for the PDF job queuing:

item newPDFJob
{
  Description = "Create PDF";
  Id = "cOCreatePDF";
  Hint = "Create PDF";
  Label = "Create PDF";
  MultiSelectEnabled = true;
  NavigationTypes = [File];
  ToolbarPaintStyle = TextAndGlyph;
  PSFile = "cOCreatePDF.ps1";
  Image="coolOrange.ico";
}

The most attributes of this section are probably self-explanatory. There are just a few things to take attention. The name of the item section must be unique and so must the Id attribute. Inside the mymenu.mnu file you will find a short description of the attributes at the top. The attribute, that we are interested in, is the PSFile, which points to a PowerShell script file. This file is located in the DataStandard\Vault\addinVault\Menus folders. Before we look to the PowerShell file, we have to define where our new menu item shall be displayed on the Vault UI. If you scroll down the mymenu.mnu, you will find further sections called “site” which describe the Vault toolbars and menu. As we like to add our menu item to the context of a file, the section we are looking for is called fileContext. It already exists, so just scroll down and look for it.

site fileContext
{
  Id="DSSiteFileContext";
  Label="myMenu";
  DeployAsPulldown=false;
  Location=FileContextMenu;
  MenuItems=[$newFile, $editFile,$NewJobPDF];
}

The attribute MenuItems contains the list of menu items that shall be displayed in the context menu. So, in our case the $NewJobPDF. Once you save the file and restart Vault, you should see your menu item like this:

menuItem

Let’s have a look to the cOCreatePDF.ps1 file. It does not exist yet, so let’s create one. And this is the content:

foreach ($selection in $vaultContext.CurrentSelectionSet)
{
  $jobParams = New-Object Autodesk.Connectivity.WebServices.JobParam[] 1
  $jobParams[0] = New-Object Autodesk.Connectivity.WebServices.JobParam
  $jobParams[0].Name = "FileId"
  $jobParams[0].Val = $selection.Id
  $text = "Create PDF for '"+$selection.Label+"'"
  $vault.JobService.AddJob("coolOrange.powerJobs.CreatePdfAsAttachment",$text,$jobParams,10)
}

The function iterates through the selected elements and for each element it adds a job into the job queue. For our job, we only pass the FileId as a parameter. So, the first couple of lines define the job parameter, while the last line adds the job to the queue with according arguments.

After next start of Vault, we will have a new menu item on the context of a file, which queues a powerJobs PDF creation for the selected files. Of course the logic of the menu item can be enhanced, so that the job gets queued only for certain file types or with some more parameters. However, that’s it. With just a few entries in the mymenu.mnu and an according PowerShell script, we have what we want.

I hope you have an idea how to create new menu items in Vault via Data Standard, an by the way, it’s worth having a look to the other menu items delivered with the standard, such as file and folder creation or edit and the like.

Posted in Data Standard, powerJobs, PowerShell, Vault API | Tagged , , , | Leave a comment

Combine Uses and Where Used

UsesWhereUsed

I’ve recently been asked how to create a tab in Vault that represents both, the use and where used of an assembly component. Immediately I thought this could be a good example for Data Standard. Basically, when you select an assembly, Vault shows you the “Use” and “Where used” as separate windows. But what if you like to expand the use, click a sub-component and see where this component is used? So, in this post I’m going to create a new tab that combines the 2 views, like this:

UsesWhereUsed

The solution for achieving this is pretty simple. We just need a tab with 2 tree-views and a bit of code for populating the tree-views. In order to keep the tab performing fast, we will collect the needed information on the go. In other words, we will collect the children only when the tree gets expanded, and we will collect the parents only when a component gets selected.

Now, a tree-view is a bit complex, as it behaves like a nested list. A list where every element has a sub-list, and each sub-element has a sub-sub-list, etc. In our particular case we want to populate the sub-elements only when really needed. So, creating an according object with PowerShell would be possible, but quite complex.

I prefer to keep the simple things in PowerShell and place the more complex things in C#, and then use that code in PowerShell.

So, I’ve created a little DLL which contains one class. That class exposes a Name (string), an Icon (image) and a Children (list) and Parents (list) property. While the Name and Icon are obvious, the Children and Parents properties collect the file associations. The getter of these properties will only be called as the user expands the tree or clicks on a component in order to see the where-used. So, the data will be required little by little. This is how the DLL looks like:

public class TreeNode
{
  Connection _con = null;
  File _file = null;
  WebServiceManager _svc { get { return _con.WebServiceManager; } }

  public string Name { get { return _file.Name; } }

  public List<TreeNode> Children {
    get {
      List<TreeNode> children = new List<TreeNode>();
      FileAssocArray[] fileAssociations = _svc.DocumentService.GetLatestFileAssociationsByMasterIds(new long[] { _file.MasterId }, FileAssociationTypeEnum.None, false, FileAssociationTypeEnum.Dependency, false, false, false,false);
      if (fileAssociations.First().FileAssocs != null)
        foreach (var fileAssociation in fileAssociations.First().FileAssocs)
          children.Add(new TreeNode(fileAssociation.CldFile, _con));    return children;
    }
  }

  public List<TreeNode> Parents
  {
    get {
      List<TreeNode> parents = new List<TreeNode>();
      FileAssocArray[] fileAssociations = _svc.DocumentService.GetLatestFileAssociationsByMasterIds(new long[] { _file.MasterId }, FileAssociationTypeEnum.Dependency, false, FileAssociationTypeEnum.None, false, false, false,false);
      if (fileAssociations.First().FileAssocs != null)
        foreach (var fileAssociation in fileAssociations.First().FileAssocs)
          parents.Add(new TreeNode(fileAssociation.ParFile, _con));
      return parents;
    }
  }

  public BitmapImage Icon
  {
    get {
      var props = _con.PropertyManager.GetPropertyDefinitions("FILE", null, PropertyDefinitionFilter.IncludeAll);
      var def = props["EntityIcon"];
      var fileIter = new FileIteration(_con,_file);
      ImageInfo prop = _con.PropertyManager.GetPropertyValue(fileIter, def, null) as ImageInfo;
      System.IO.MemoryStream ms = new System.IO.MemoryStream();
      prop.GetImage().Save(ms, System.Drawing.Imaging.ImageFormat.Png);
      prop.Dispose();
      System.Windows.Media.Imaging.BitmapImage bImg = new System.Windows.Media.Imaging.BitmapImage();
      bImg.BeginInit();
      bImg.StreamSource = ms;
      bImg.EndInit();
      return bImg;
    }
  }

  public TreeNode(File file, Connection con)
  {
    _file = file;
    _con = con;
  }
}

The most complex part is the extraction of the file icon. As you can see, the constructor of this class requires a file (Vault file object) and a Vault connection.

So, the PowerShell implementation is pretty short, as we only have to gather from Vault the currently selected file and pass this file to the DLL including the current Vault connection. As we get the first node (root node) from the DLL, we simply set the ItemsSource of our left TreeView (Uses) to our root node. The user can now expand the Uses TreeView and more and more data will be loaded. The following code is stored in a separate PS1 file called UsesWhereUsed.ps1 located in the Data Standard Vault\addinVault folder.

 
Add-Type -Path 'C:\ProgramData\Autodesk\Vault 2015\Extensions\DataStandard\Vault\addinVault\UsesWhereUsed.dll'

function OnTabContextChanged_UsesWhereUsed
{
  $xamlFile = [System.IO.Path]::GetFileName($VaultContext.UserControl.XamlFile)
  if ($VaultContext.SelectedObject.TypeId.SelectionContext -eq "FileMaster" -and $xamlFile -eq "Uses - Where used.xaml")
  {
    $file = $vault.DocumentService.GetLatestFileByMasterId($vaultContext.SelectedObject.Id)
    $treeNode = New-Object UsesWhereUsed.TreeNode($file, $vaultConnection)
    $dsWindow.FindName("Uses").ItemsSource = @($treeNode)
  }
}

As you can see, the PowerShell code loads the DLL from the according folder, so have the DLL in such folder, and then offer a function OnTabContextChanged_UsesWhereUsed. We will have to add this function in the OnTabContextChanged function of the default.ps1 file, like this:

function OnTabContextChanged
{
  OnTabContextChanged_UsesWhereUsed
  ...
  ....
  ..
}

At the beginning we spoke about the tab. So, the file UsesWhereUsed.XAML shall be located under Data Standard\Vault\Configuration\File. The first TreeView for the Uses looks pretty simple:

<TreeView x:Name="Uses" Background="{x:Null}">
<TreeView.ItemTemplate>
<HierarchicalDataTemplate ItemsSource="{Binding Children}">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="auto"/>
<ColumnDefinition Width="auto"/>
</Grid.ColumnDefinitions>
<Image Source="{Binding Icon}"/>
<Label Content="{Binding Name}" Grid.Column="1" />
</Grid>
</HierarchicalDataTemplate>
</TreeView.ItemTemplate>
</TreeView>

In order to display correctly the Icon and the Name, we define a HierarchicalDataTemplate with a little Grid in it. The HierarchicalDataTemplate offers the ability to define where the child elements shall come from, so you see the additional ItemsSource set to Children.

The TreeView for the WhereUsed looks pretty much the same, except for the binding of the HierarchicalDataTemplate that obviously points to the Parents, and the ItemsSource of the TreeView itself, which points to the selected item of the Uses TreeView.

<TreeView x:Name="WhereUsed" ItemsSource="{Binding SelectedItem.Parents, ElementName=Uses, Mode=OneWay}" Background="{x:Null}">
<TreeView.ItemTemplate>
<HierarchicalDataTemplate ItemsSource="{Binding Parents}">

In other words, when you select an element in the Uses TreeView (left side), the WhereUsed TreeView gets notified and filled with the Parents of the selected item. So, the 2 TreeView talks to each other by themselves.

Here you can download the complete package including the source code for the C# DLL https://github.com/coolOrange-Public/UsesWhereUsedTab/archive/master.zip

I hope that with this example, you see how easily XAML, PowerShell and C# can work together to achieve cool things with relatively few code.

Posted in Data Standard, PowerShell, Vault API | Leave a comment

Create a folder tree from a template

blogCreateFolderFromTemplate

In the past few weeks, many of you asked this question: “how to create a folder in Vault by copying the folder tree from another template folder?”. In this post, I’m showing you how to do this with Vault Data Standard.

There are basically 2 steps to do. The first is to enhance the standard folder dialog by adding a combobox where you can select a template folder. The second is to copy the complete folder tree from the template folder to the new generated target folder.

Let’s start with the dialog. You have to add an additional row to your dialog,  a label and a combobox. This is how it looks on my side

<Label Content="Template" Grid.Column="0" Grid.Row="4" />
<ComboBox ItemsSource="{Binding PsList[GetListOfVaultProjects]}" SelectedValue="{Binding Prop[Template].Value}" Grid.Column="1" Grid.Row="4" />

As you can see, I bind the ItemsSource of the combobox to a PowerShell function called GetListOfVaultProjects, and the SelectedValue to a Vault property called Template. This means that we have to create a Vault property named Template and map such property to the Folder categories. We also have to create the PowerShell function with the name GetListOfVaultProjects. For this purpose, I just created a new PowerShell file and placed it into the addinVault folder of Data Standard. This is how my function looks like

function GetListOfVaultProjects()
{
     $dsDiag.Trace(">> GetListOfVaultProjects")
     $designsFolder = $vault.DocumentService.GetFolderByPath("$/Designs")
     $subFolders = $vault.DocumentService.GetFoldersByParentId($designsFolder.Id,$false)
     $projectFolders = $subFolders | Where-Object { $_.Cat.CatName -eq "Project" }
     $listOfProjects = $projectFolders | ForEach-Object { $_.FullName }
     $dsDiag.Trace("<< GetListOfVaultProjects")
     return @($listOfProjects)
}

As you can see, the function looks to all Folders underneath $/Designs and picks only those that are of category “Folder”. If you like to have your template somewhere else, then just adjust the folder, and in case, also the category. You may wonder why the return value is embedded in a @(…) in the last line. The reason is that in case you only have one template, PowerShell reduces the array (list of values) down to one single value. But we need a list of values, worst case either an empty list or a list with at least one element. As in PowerShell an array is create with @(), by embedding the variable into @(), we ensure that in case there is only one or no values, an array is still returned.

Anyway, the next step is to enhance the PowerShell script that creates the Folder (addinVault/Menus/CreateFolder.ps1). In this script, we will recursively recreate the same folder structure as defined in the selected template folder. As we don’t know how deep or articulated the folder structure might be, we create a little recursive function that goes into the tree and recreates step by step the folder tree for the target folder. This is the function

function recursivelyCreateFolders($targetFolder, $sourceFolder)
{
     $sourceSubFolders = $vault.DocumentService.GetFoldersByParentId($sourceFolder.Id,$false)
     foreach ($folder in $sourceSubFolders) {
          $newTargetSubFolder = $vault.DocumentServiceExtensions.AddFolderWithCategory($folder.Name, $targetFolder.Id, $folder.IsLibrary, $folder.Cat.CatId)
          recursivelyCreateFolders -targetFolder $newTargetSubFolder -sourceFolder $folder
     }
}

We basically pass the source and the target folder and let the function go into the child folder of the source and recreate them at the target. For each folder found in the source, the function calls them with the according child source and target folder. So, the function will go down the tree itself. It’s important that this function is written at the top of the script file, as script files are read from top to bottom. So, when we later call the function, the function must already be known.

Now we can call the function right after the new folder has been created, like this:

if($result)
{
      #new folder can be found in $dialog.CurrentFolder
      $folder = $vault.DocumentService.GetFolderById($folderId)
      $path=$folder.FullName+"/"+$dialog.CurrentFolder.Name

#create template folder tree
      $newFolder = $vault.DocumentService.GetFolderByPath($path)
      $template = $dialog.ViewModel.Prop["Template"].Value
      if($template -ne "")
      {
           $templateFolder = $vault.DocumentService.GetFolderByPath($template)
           recursivelyCreateFolders -sourceFolder $templateFolder -targetFolder $newFolder
      }
...
..
...

And this is how it looks once it’s finished

createFolderFromTemplate

As you can see, when you now create a new folder, you can pick from a list of templates and no matter how the structure in the selected template looks like, the new folder will have the same children.

Of course this sample can be extended, for instance by applying some properties of the new folder to the child folders. Or by copying also some files from the source to the target. Or by renaming the child folder with a prefix from the originator folder. Or… you get the idea. In this sample, the template folders are within Vault, but they can also come from an external source, such as your ERP or similar. So, the possibilities are endless. The logic remains almost the same. Yes, there is a bit of code to write, that is obvious as somewhere we must teach Vault to do what we like, but I’m still delighted by the shortness of the code.

I hope you enjoyed this sample and comments are welcome as always!

Posted in Data Standard, PowerShell, Vault API | Tagged , , , | 4 Comments

Ready for 2015 R2

2015R2b

Hi everyone, as of today the coolOrange products are ready for Vault 2015 R2 and can be downloaded from the website. All the cool features are now available for Vault 2015 R2 at no additional cost. So if you already have a 2015 license, you can activate the according product also for the 2015 R2 Vault release. If you don’t have a license, well, then it’s time to get one ;-)

As Vault 2015 R2 has some visible enhancements, we had to adapt our products accordingly. So when you download your preferred product from our website, you will find links for 2015 and 2015 R2. Make sure you pick the right one. This is valid for powerJobs, vaultRuler, dataLoader. The bcpChecker and the bcpDevkit are an exception, as they work with all BCP versions from 2012 onward, and now also with 2015 R2.

Have fun working with the R2 products!

Posted in Uncategorized | Tagged , , , , , | Leave a comment

New version of bcpChecker available

bcpChecker

We recently released a new version of the bcpChecker. The bcpChecker allows you to open a Vault BCP package and navigate through the content in a Vault-similar UI. This saves you a ton of time and headaches when you are working on a Vault migration project.

The new version let’s you navigate also through items, BOMs and links, additionally to folders and files. This way, you can check the quality and structure of your BCP package before you start a 10+ hours import into Vault. Thus you can check for correct categories, lifecycle, states, properties, folder structure, file naming, etc. You basically see the outcome of the import before you start the import.

bcpChecker

In the current release you can also check if a file exists for all entries in you BCP package, and so avoid annoying errors during the import. Also, you can get a report of all used behaviors and check against your Vault whether you really have defined all the properties, life-cycles, categories, etc. that are required for a correct import of the BCP package.

Beyond the visual checks you could also perform some queries and verify that all references can be resolved, all items have appropriate files, etc. Or you may correct some smaller issues by manipulating the BCP package and re-export the corrected version.

So, in case you plan to perform a migration to Vault using the Vault BCP, which we can only suggest, take a look at the bcpChecker. It will save you stress and will help even your customer to see the actual end-result before the import really starts.

Posted in Migration, Vault BCP | Tagged , , , , , | Leave a comment

Rule your Vault

vaultRuler-Banner

We just released a new version of the vaultRuler. A powerful tool that applies category rules to all the files in your Vault. The new version additionally allows you to force the lifecycle definition and property assignment for those files that are already in the right category. And you can also reinforce the rules for all files in your Vault.

You may have just moved from Vanilla Vault to Vault Workgroup or Professional, have a huge amount of files, all in category Base, and want to bring them into the appropriate category. Or you have already Vault Workgroup or Professional, you changed some behaviors and want to bring existing files into the right shape. In both cases the vaultRuler will be a huge help.

vaultRuler-animation

This new version allows you to apply the lifecycle definition and property assignment also to those files that are already in the right category. Or, you may apply the rules to all files, regardless of the category.

So, let’s suppose you’ve worked with Vault for a while and you realize you need a few more properties. No problem. Just add the properties in the Vault configuration, assign them to the category you think is appropriate and all new files will have such properties. But what happens to the existing files? Well, the properties will be added only if you eventually change their value.

The alternative is to use the vaultRuler. It goes over all of your files and brings them again into the defined rule.

The applications for vaultRuler are manifold. The use is always the same. Configure the Vault as it best suits you, and then let the vaultRuler bring all your files into the right settings. The different options of the vaultRuler will allow you to selectively apply the configured rules. Download the vaultRuler now and see for yourself.

Posted in Migration | Leave a comment