Extract Username Parameter

Revit
1

Hi. Is there a way in Dynamo to extract the username (autodesk id) parameter and copy to an instance text parameter? Any suggestions? Thanks in advance

2

Hi

Edit:
And to send
https://dictionary.dynamobim.com/#/Revit/Elements/Element/Action/SetParameterByName
cordially
Christian.stan

3

Thanks This is great! I plan to use this and transfer the value to a working view instance text parameter. How does this work once multiple users jump in and work on the workshared model? Thanks in advance

1 Like
4

hi
Sorry, this is outside my scope of expertise.
Others will no doubt answer you
cordially
christian.stan

5

Well, only one person can own an element at once, so if you plan on modifying that parameter on each update in the view you’ll need to make sure team members are communicating about who is doing what.

What is your end goal?

6

Hey @jacob.small Im hoping to grab the current username value and copy it to a text instance view parameter only when that current user creates a newworking view. Hope this makes sense at all. Thank you

7

Will they create the working view with Dynamo? If not, what if a user creates the view without Dynamo open?

8

I dont see these users creating new views using Dynamo…only via traditional method.

9

Ok. And will they know they have to run the graph afterwards every time?

10

Was hoping its automatic.

Is this a stretch? :slight_smile:

11

Yes - Dynamo will only run on command.

You can try to build an event listener which triggers a graph and bind that to the session, but each user will have to run that command at the start of the session which they likely won’t as if they would do stuff like that they would just set the parameter on their own…

All hope is not lost though.

Why do you want this info?

12

as you can see from sample below and this is primarily to organize working views in our project browser, wanted to see if we can automate the username value here so users don’t need to manually enter their name or initial as it sometimes leave ??? when users don’t follow protocols and enter their initials thus make project browser look messy. hope this clears the intention here. thanks all

image
image333×747 17 KB

13

So you have some options.

  1. Teach people to open Dynamo/Player and run a graph every time they make a view. The graph would set the parameter value. This is easiest, but will require the users do something and they aren’t fans of that now so… maybe not a good choice.
  2. Teach people to open Dynamo/Player and run a graph every time they start Revit. The graph would add an event listener to trigger running the same graph as #1 any time someone adds a view to the model. The benefit here is that once the command is bound users don’t have to do anything else - so the ask is two or three clicks. The drawback is that it’s still two or three clicks and Revit won’t be as stable as this type of event listener doesn’t permit proper shutdown and error handling procedures as Dynamo can’t send subsequent commands to control such as it isn’t there anymore.
  3. Write an add-in instead of a graph. This would work just like #2 but without the stability issues. The drawback is that you’d need to learn to write the add-in (not that much more learning as the use case is fairly basic), but you would need to deploy and maintain that tool over time which is a good bit of work.
  4. Don’t do this on view creation at each users station, but use it as a clean up tool that addresses the parameter on all views in the model on demand. So rather than asking everyone to do something or deploy everything to every user, one person runs the tool say once or twice a day / week / month as appropriate. That graph looks quite different though.

If you go with number four the logic will be a good bit different, with seemingly the hard part will be identifying the user. You can try something like this:

  1. Get all views.
  2. Filter out views which meet the standards for non-working views. Basically get parameter value by name to identify the “view category” parameter value, then test for it being ‘wip’. You may also want to get any which are null (created views which didn’t get a view category assigned) for additional Q&A/cleanup.
  3. This part I am a little less sure of as I haven’t tried it, but in theory it should work as it does for other classes of elements. Get the worksharing tooltip info for the remaining views (I believe Archilab has a node for this). Get the ‘created by’ value from the tooltip, that should be the Revit username of the person who made the view. If that doesn’t work you can always just delete the views which are older than X units of measure - people usually start to follow standards pretty quickly when it means they’ll have to redo things.
  4. Set that value to the ‘view subcategory’ with a set parameter value by name.

Now this method would require someone take action, and that someone is cleaning up after the users which isn’t ideal. But it means everyone can quickly do this rather than someone manually taking awhile, and users can use it themselves after creating views just like option 1, and it means you don’t need to learn C# and deploy an add-in.

14

I guess I have my work cut out and a lot of soul searching on this one. Haha thanks for all the input! Appreciate you

1 Like
15

This is all headed the wrong direction. The information is already being stored in a workset enabled project. You only need to look at the WorksharingTooltipInfo. Revit has already done the work for you,

WorksharingTooltipInfo,Creator
WorksharingTooltipInfo.Owner
WorksharingTooltipInfo.LastChangedBy.

Applies to all elements. No fancy stuff required. I just added that to our standard pyRevit toolset last week for isolating elements per selected user. Who made it. Who has it. Who changed it. Basic API always rocks.

1 Like
16

Yeah - this is the class I indicated in my post above.

One thing to note: you likely want to classify it in a parameter all the same as the first time you make a new central in a local network you become the owner and creator of all elements. Similar automation tools and clean up can cause the same, so relying on the tooltip outside of the initial day of creation isn’t recommended.

17

…and if you really must automate that into parameters - it should be a pyRevit hook that requires absolutly no user interaction. But for most uses, a simple dialog reporting this info should suffice. Or a pyRevit updater - but that’s more overhead than this really deserves.

myview = doc.ActiveView
worksharingtooltip = WorksharingUtils.GetWorksharingTooltipInfo(doc, myview.Id)
creator = worksharingtooltip.Creator
print(creator)
owner = worksharingtooltip.Owner
print(owner)
editor = worksharingtooltip.LastChangedBy
print(editor)
18

Which can be leveraged if you are doing prototype work or rolling projects into a new phase. The elements can essentially be marked as “Approved”. You’ll need to play some games with an account user name. But then as a project goes from permit issued for construction to construction administration - you’ll know what was changed and who changed it.

1 Like
19

So not operating in a named user environment with single sign on yet? :smiley:

Personally I prefer tracking by unique ID, which includes the episode ID in it, which can be track back to not only ‘who’, but ‘when’. Very useful if you collect everything needed to implement it and you can start to draw conclusions on time to make changes during later phases - changes to something with an early version and episode ID has more down stream impact than something added the third to last version/episode ID.

20

Yes we are. But you can mess with that.