Event Source Serialization Issues
wmagnuson opened this issue · comments
Is your feature request related to a problem? Please describe.
The Box Json conversion logic has several current limitations that cause issues with any client that attempts to use serialization/deserialization of raw enterprise events and their associated event sources internally in their systems. Several objects cannot be reliably reconstituted from the serialized strings produced by the BoxJsonConverter. This causes client code to use complex workarounds that could more easily be handled in the SDK itself. These proposed changes are an attempt to resolve these serialization issues.
Describe the solution you'd like
The first change is adding event source definitions for externally shared events. Unlike an internal box file collaboration event source that has a user, an external user collaboration just has a user_email . I’m proposing to add a new ExternalUserFileCollaborationEventSource and ExternalUserFolderCollaborationEventSource .
"source": {
"file_id": "77777",
"file_name": "file.txt",
"user_email": "testuser@example.com",
"parent": {
"type": "folder",
"name": "All Files",
"id": "0"
},
"owned_by": {
"type": "user",
"id": "33333",
"name": "Test User",
"login": "testuser@example.com"
}
}
The owned_by property is also missing and would be useful to have on all of the event source models.
"source": {
"item_type": "file",
"item_id": "77777",
"item_name": "file.txt",
"parent": {
"type": "folder",
"name": "All Files",
"id": "0"
},
"owned_by": {
"type": "user",
"id": "33333",
"name": "Test User",
"login": "testuser@example.com"
}
}
Finally, the conversion logic isn’t idempotent due to the addition of a Type on some of the event source models that does not exist on the stream object. Essentially, if you try to deserialize → serialize → deserialize again, it fails as it thinks the object is a file, folder or group rather than the correct event source object. The proposed change is to remove that type as it’s not part of the original object. This would impact BoxGroupEventSource, BoxGroupFileCollaborationEventSource, BoxGroupFolderCollaborationEventSource, BoxUserFileCollaborationEventSource and BoxUserFolderCollaborationEventSource . Per the above json example, BoxFileEventSource and BoxFolderEventSource do have an item_type so their Type property would remain and as it’s an item_type not type in the enterprise event, it doesn’t have the same serialization issues the other event sources do.
Hey @congminh1254 ,
Thanks for taking a look at this so fast! It does address the one issue of the missing owned_by property, however the serialization issues for the external user collaboration and the other event sources still exist. I do have a forked repo that does contain the fixes in it and would be happy to put up a pr myself to save on duplication of effort. I maybe should have mentioned I already had the changes done in the issue, so sorry about that! Let me know if that works or I should add more comments to the pr.
Hi @wmagnuson
Thanks for your update, I will check for fork tomorrow and check if something is missing in my PR.
At the same time, if you found anything else can be improved, you are more than welcome to create a pull request to our SDKs.
Best,
Minh
Hi @wmagnuson
Please take a look at my PR, so we are combining the BoxExternalUserFileCollaborationEventSource and BoxUserFileCollaborationEventSource to the same object, and the same thing with Folder.
About the type fields, we are are not removing it as it may cause the breaking changes to the exist customer of the SDK, but we use the decorator [JsonIgnore] to prevent this field when serialize, so this field will not show up in the JSON.
I see that in your code you have the unit tests for BoxJsonConverter, will you mind if we include this test in my PR?
Thank you,
Minh
Feel free to pull in the unit tests. It looks good! Thank you!