Hello! 
The current Revit connector (not sure which version started it) isn’t uploading the correct value for the type name anymore (null instead) … at least not as parameter. This has been different for previous connector versions.
I just noticed that, and I’m not sure how big the scope of that is and what else might be affected.
I guess that’s not indended? A bug?
Thanks, @samberger we can investigate.
Are you finding a use-case where you need the value in the global ‘parameter.ALL_MODEL_TYPE_NAME.value’ as opposed to the resolved ‘type’ parameter?
So, was this a value we were reporting correctly before, and potentially, this is a regression? How did this come to your attention?
Yes … earlier connector versions uploaded that value correctly.
If each commit would also save the used connector version (which I would love anyways), I could tell you. 
But I think it’s been 2.15 … definitely 2.14 or above.
Regarding the use case:
In our parameter-editing-app, I would like to process/handle that value the same way as any other parameter… (although apparently just for read access, since it’s read-only).
… which actually leads to the idea, that it would be really nice, to change the revit family type by changing that value (and hopefully matching an existing type 
).
Actually, I can check what combination of type-checking we are performing on Receive in Revit and if doing such exotic editing would trigger the type mapper into action. I’ll consider this a side-mission.
Hi!
I have to add another missing value. 
It’s basically the same problem, I guess. The applicationUnitType for all parameters are uploaded as null with the current Revit connector (version 2.17). As for the initial issue, this has worked with previous connectors.
It’s even visible in my previous screenshots, but here is another example:
+1 on that 
Hello!
(Both issues still apply for the Revit connector 2.18.0, and) I wanted to add another one here, because it’s also about the Revit connector and missing data:
Revit model groups can have parameters, as any elements in Revit. Those don’t seem to be exported to Speckle though.
In the frontend viewer those model groups seem to be “exploded”/ignored anyways (which might be the expected behaviour) and thus those parameters wouldn’t be displayed anyways.
But it would be nice to still have them uploaded into the database, so one could still access them via API whenever needed. … Just as parameters object, as for any other built elements.
Cheers!
Regarding the last one (missing parameters{} object for Revit model groups, I tried to add the necessary code to the speckle-sharp converters.
So far, I haven’t done anything for the connectors before and I haven’t set up any test environment, so I couldn’t even really test it myself (perfect conditions, I know… 
). But I could copy/adapt the most from the other converters (DB.Elements), so it might actually work. 
If it looks realistic or if it’s more handy for you anyways, I could also create a pull request.
Otherwise feel free to do it your style.
Please raise a PR - this will make what you are changing clearer.
We are undergoing a slight refactor for the better in connectors and converters right now, so we will likely adopt your changes (if we can see them working) in a different format. We’ll be sure to add you as a contributor, though.
This is expected behaviour; groups from many software are a collection that spans collections. We have thoughts on handling this in the future, but it isn’t strongly supported for now.
