Bulk Requests are intentionally omitted from Scimitar. I am willing to add them, but It would require some refactor on how we extend behavior to SCIM.
Scimitar currently exposes an extendable ResourcesController, and a generic implementation of ActiveRecordResourcesController to support ActiveRecord. To add a controller to your SCIM endpoint, you then extend this controller and replace the right methods. This implementation keeps at the controller level logic needed for the Bulk Requests, and my proposal is to extract what is in ActiveRecordResourceController into an adapter structure, where Scimitar would have a default mounted ResourcesController, which would handle the internal actions. This is how the configuration of Scimitar would look like:
Scimitar.engine_configuration = Scimitar::EngineConfiguration.new({
# ...
resource_types: {
"Users" => ActiveRecordAdapter.new(User), # futher overrides as we have today can be easily done by subclassing this adapter class
"Groups" => ActiveRecordAdapter.new(Group),
"Departments" => ActiveRecordAdapter.new(Department),
},
# ...
})Internally, the now directly mounted ResourcesController could delegate the handling of the request to each adapter exactly how it happens today. This would enable us to use the same mechanism to implement a Bulk Request, which would basically do the same mapping of resource type / HTTP verb to the adapters.
Since group memberships are only written to Group resources, syncing user groups becomes a huge bulk request that has to be supported by either the client or the server, and we could benefit from having it on Scimitar as an atomic transaction.
Bulk Requests are intentionally omitted from Scimitar. I am willing to add them, but It would require some refactor on how we extend behavior to SCIM.
Scimitar currently exposes an extendable
ResourcesController, and a generic implementation ofActiveRecordResourcesControllerto supportActiveRecord. To add a controller to your SCIM endpoint, you then extend this controller and replace the right methods. This implementation keeps at the controller level logic needed for the Bulk Requests, and my proposal is to extract what is inActiveRecordResourceControllerinto an adapter structure, where Scimitar would have a default mountedResourcesController, which would handle the internal actions. This is how the configuration of Scimitar would look like:Internally, the now directly mounted
ResourcesControllercould delegate the handling of the request to each adapter exactly how it happens today. This would enable us to use the same mechanism to implement a Bulk Request, which would basically do the same mapping of resource type / HTTP verb to the adapters.Since group memberships are only written to Group resources, syncing user groups becomes a huge bulk request that has to be supported by either the client or the server, and we could benefit from having it on Scimitar as an atomic transaction.