-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support non-dynamic object types #159
Comments
Could we/should we do something with mapping? For example, come up with our own guids for the objects then if those guids are used, we handle them a special way. This way as those objects become supported by Relativity it would be a matter of just removing them from the mapping dictionary and everything should still just work? |
That would work as well. |
We are in agreement the reference should be by Name vs Guid for these objects. |
Right now, you need an object type Guid (as the input to
RelativityObjectAttribute
to define a Gravity class . This excludes all non-dynamic object types, such as saved searches and fields, from being present in a Gravity model as associated objects. At @Milyli, these field types frequently show up in configuration RDOs, limiting Gravity's usefulness.We should allow object type to be defined by an ArtifactType as well for these scenarios (e.g.
[RelativityObject(14)]
for a field).The fields themselves have Guids, so the other attributes would not need new overloads.
This might be easier to do after #158.
The text was updated successfully, but these errors were encountered: