Closed doreilly closed 1 year ago
After our conversation, it seems like the least difficult way of moving forward is to avoid codifying any platform API interfaces into the library at present, but to have a model that can house and reflect what exists on the platform. I've removed what's in this PR to just the data model (with a migration forthcoming).
I'm happy to discuss any changes (e.g. names or field nullability).
This is an attempt to bring AGS support to a releasable state.
LineItem
storageThis PR includes an
LtiLineItem
model that maps tolti1p3.lineitem.LineItem
instances. The interface isn't identical, so there's a conversion necessary—there's ato_line_item
method, in much the same wayto_registration
is onLtiRegistration
. Conversion from anlti1p3
instance is handled inservices.ags
, both for a singular instance, or for a bulk synchronization using the AGS service provided bylti1p3
.What's MVP?
Looking at #25, I think we may want to refine the acceptance criteria. Reflecting on it, I'm thinking that we may wish to leave
score
andresult
features with the tool project. I can see a case for maybe holdingresult
instances, but I'm guessing the how and what of that may be better left to the tool. So, I suppose my proposal is to refine/iterate on the code structure of this PR, and accept the first two listed priorities of #25, while punting on the final two.TODO
Add some test coverage