Closes#3511, Closes#3512, Closes#3526
- show* methods now close existing passive notifications by
default. They also now take an optional options object where
existing parameters such as "delayed" and "defaultErrorText"
can be passed in as well as the new "doNotClosePassive" flag.
- Removed all explicit calls to notifications.closePassive except
for the few places where it makes sense to call it separately.
closes#3012
- Inject notification object into router
- Listen to didTransition / observe currentPath to close notifications
- Close notifications on successful save actions
fixes#2999
- handle undefined argument in openModal function
- catch whether a model is deleted in Editor routes to aid transition
- move updateTags function to the PostModel
- add call to updateTags in delete-post modal
No issue
-inject popover:service into modal component delete post
controller so popover close can be triggered as part of
the delete action
-remove unnecessary 'needs' from the delete post controller
Closes#2849
-wire up delete post action in ember admin
-refactor ember modal dialog
-override RESTAdapter.deleteRecord to workaround Ember expecting
an empty response body on DELETEs
resolves#2416
This is a pretty large commit but what it's adding are pretty fundamental to the admin app.
- Creates top level actions on the ApplicationRoute for opening and closing modals. This allows sending the 'openModal' action from any template to open a modal.
- Every modal template lives in 'templates/modals/{{modalName}}'
- Each modal can have a backing controller of the same name that can provide additional control for that modal. Those controllers reside in 'controllers/modals/{{modalName}}'
- Created the ModalDialog component which is where all the logic for the component resides. It's not at 100% parity with the existing Ghost modal system but it has the foundation for further fleshing out. It currently accepts parameters for styling how the modal should appear, which previously was defined in JS files in the Backbone admin.
- This creates the 'delete all posts', 'delete this post', 'markdown', and 'upload' modal. Some are in more stages of completion than others, but I wanted to just get the foundation in place as fast as possible.
- This also creates the UploadModal component which is a subclass of the ModalDialog component. The reason for this subclassing is that the UploadModal component directly accesses the DOM and when that occurs in Ember it should remain in a component definition. It's ready for extending to reach parity. Note: depending on needs the base ModalDialog class may need to be modified.
