Edit Family Command ID

[grahamcook]

I’m trying to use the new 2013 RevitCommandId class to intercept the Edit Family command.  Our intention is to design some access rights into some of the families we would prefer to lock down.  Perhaps linking with Active Directory groups.

Problem is I can’t find the commandId of Edit Family.  It doesn’t seem to have one or certainly doesn’t show in the Journal if i run the command in the UI then review.

[saikat · Accepted solution]

Hi Graham Cook

I had some detailed discussions on this with the Development team and it seems the Edit Family cannot be blocked when called in from the Ribbon - it does not invoke the command. So your suggested workflow of using the CommandId to block the Edit Famiily to perform certain custom checks/steps will not be possible.

You might have to think of some other workflows like, for example, using Events to handle opening of Family files in Family Editor and then checking/performing your custom steps.

Hope this helps

cheers 

[grahamcook · Accepted solution]

Thanks for clarifying that Saikat.

I'm now looking at the alternative workflow by using events as you have suggested.  It looks like I can achieve my goal by hooking into the ViewActivated event and then checking if the document in the view is a family.  If true I perform my custom steps to establish permissions and if its found the user is not authorized pop up a message and close the document (family editor).

I note that document.close() doesn't work but a work around (and dangers of this approach) is in one of Jeremy's blogs:

http://thebuildingcoder.typepad.com/blog/2010/10/closing-the-active-document-and-why-not-to.html

Despite the dangers of this approach, closing the view is the only way I can think of to interupt the normal flow.  So a simplified version of the code by way of example now looks like this:

private void OnViewActivated(object sender, ViewActivatedEventArgs e)
{
	if (e.Document.IsFamilyDocument)
	{
		// custom checks here, AD checks,
                // list of protected families, etc
		// bool allowEdit = false;
		// etc
		//-------------------
		
		if (allowEdit == false)
		{
                      TaskDialog.Show("Permission Denied",
                      "This is a protected family.  Please contact xxxx 
                       if you wish to make changes.");
		
     	               System.Threading.ThreadPool.QueueUserWorkItem(new 
                             System.Threading.WaitCallback(CloseDocProc));
		    
                      return;
		}
	}
}

static void CloseDocProc(object stateInfo)
{
	try
	{
		// maybe we need some checks for the right 
		// document, but this is a simple sample...
		System.Windows.Forms.SendKeys.SendWait("^{F4}");
	}
	catch (Exception ex)
	{
		Util.ErrorMsg(ex.Message);
	}
}

[saikat]

Thanks for the update Graham.

Another workaround could be to open another specific Revit Document using the API, make that as active and now your current document would be in the background (the one you want to close) and you should be able to close this one with the API.

But you would still have a Revit document open (which might not be even relevant to your workflow). Just thought will let you know about this - though your current unsupported workaround might  suit you best.

cheers

[Anonymous]

You might also look at the DocumentOpening event. I use this event to prevent our CADD Users (an AD Group) from opening a central model directly. Only users in our CADD Support AD Group can open a central model directly. Below is a snippet of possible code. This may only work if the family is selected through the File Open dialog. I have not tested this with families but do use something similar for our .RVT files.

public static class DocumentOpeningHandler
{
 public static void Handler(object sender, DocumentOpeningEventArgs e)
 {
 // use AD Groups to determine who can work on specific documents
  bool canOpen = ActiveDirectoryUtility.IsUserInCaddSupport() || ActiveDirectoryUtility.IsUserInCaddCommittee();

// determine docType from e.Pathname extension
    // branch our processing based on the type of Document
  switch(docType)
  {
   case Enums.DocumentType.Unknown:
    return;

   case Enums.DocumentType.Family:
    if (!canOpen)
    {
     TaskDialog.Show("Permission Denied", "This is a protected family.  Please contact xxxx if you wish to make changes.");
     e.Cancel(); // cancel the opening of the family
     return;
    }
    break;

   case Enums.DocumentType.FamilyTemplate:
    if (!canOpen)
    {
     TaskDialog.Show("Permission Denied", "This is a protected family.  Please contact xxxx if you wish to make changes.");
     e.Cancel(); // cancel the opening of the family
     return;
    }
    break;

   case Enums.DocumentType.ProjectTemplate:
   return;
  }
 
  if(canOpen)
  {
   // allow further processing
  }
 }
}

[Anonymous]

Hi,

I'm trying the same thing and the documentopening event seemed like an excellent way of preventing users from opening families. If not for security, but for avoiding the annoying dubbleclick to open family problem when editing tags.

However the event doesnt seem to fire when opening a family using the edit family UI command.

Any thoughts?

/Erik

[michael-coffey]

8 years later and I'm still trying to figure out if there is an event associated to the Edit Family command.  There doesn't appear to be any in 2022.  There is a workaround to use the ViewActivating or ViewActivated events but then you need more workarounds to close the family after it is opened.

Did you find anything for your case?

[ARAVIND24CHANDRASEKAR]

Have you got any solutions now?