Refactors creating and previewing deliveries #25
Conversation
- Working in controllers, have reduced select-project and select-recipient - Have not touched template code yet - Need to implement project permission testing and filtering out bad users
- user list sorting was causing the userSelectionChanged event to fire because it updated the list
… to set fromUserId
- transitionToRoute params building is ugly. May want to bind in queryParams in processBack/processNext - Still have some missing functionality'
- Removes queryParams - Replaces actions and transitionToRoute logic with link-to in template - Removes custom setters/getters based on ids in favor of aliases to the model fields
- Uses the forceReload flag on the model hook to prevent us from see a partial list
…selection - Updates project listing component to observe the selectedItems array and call the action when that changes (rather than leak implementation details of the underlying ember-models-table - Adds action hooks (willPerform, didPerform, didFail) in base.js
…fferent - just moved things into the service and set a property on the service
… much different" This reverts commit 4198aa0.
Used in new delivery
This controller passes the delivery as a relationship from transfer that may not have been loaded yet, so we need to check if the model is loaded (and resolve) before calling preview()
- restores sorting on user list, since we're not handling displayDataChanged anymore
- Ember link-to adds an 'active' class if the route matches. Apparently 'deliveries' matches 'deliveries.new.select-project'?
- Moves logic for setting the fromUser here, since it's concerned with its primary model - Makes the controller available for injection to the tests
- Instead following ember's recommendation to set in route.setupController - Since there are multiple routes, done with a Mixin
app/components/delivery-preview.js
Outdated
| if(delivery.get('isLoaded')) { | ||
| delivery = Ember.RSVP.resolve(delivery); | ||
| } | ||
| delivery.then((loadedDelivery) => { |
There was a problem hiding this comment.
Had to read this a couple times to figure out what is going on:
If delivery is not a promise make it one.
There was a problem hiding this comment.
I updated the comment around this. I still don't like how this works but have been digging in to understand why it's not working.
The underlying issue is that when I create a{{delivery-preview}} component in resend-confirm.hbs, the delivery object I provide is model.delivery, where model is a duke-ds-project-transfer.
When delivery-preivew.js accesses that delivery, it's a DS.PromiseObject. DS.PromiseObjects do not a have a preview() method, so the promise needs to be resolved to a "real" delivery before calling preview(). If I call delivery.get('preview')(), it does seem find the function, but then it's not bound to the right this.
Using {{delivery-preview}} from deliveries/new/confirm.hbs doesn't have this problem. That delivery object is the model for the route, so by the time it gets to the template, it's fully loaded and resolved.
Perhaps the best (and conventional) solution is for the deliveries/show/confirm-resend route to return the delivery as its model. The transfer can be accessed as a model from deliveries/show
|
|
||
| /* May override */ | ||
| disableNext: false, | ||
| working: false |
There was a problem hiding this comment.
Is working used anywhere?
There was a problem hiding this comment.
No, not anymore. I experimented using it to show a loading indicator when fetching project permissions, but didn't have an obvious place to put that indicator.
|
Confirm delivery/preview page error if user clicks refresh: |
|
Fixes #19 |
delivery