91383269b9
This sounds a bit 'backwards' as the end goal here is to add an improved UX to partitions, not namespaces. The reason for doing it this way is that Namespaces already has a type of 'improved UX' CRUD in that it has one to many relationship in the form when saving your namespaces (the end goal for partitions). In moving Namespaces to use the same approach as partitions we: - Ensure the new approach works with one-to-many forms. - Test the new approach without writing a single test (we already have a bunch of tests for namespaces which are now testing the approach used by both namespaces and partitions) Additionally: - Fixes issue with missing default nspace in the nspace selector - In doing when checking to see that things where consistent between the two, I found a few little minor problems with the Admin Partition CRUD so fixed those up here also. - Removed the old style Nspace notifications |
||
|---|---|---|
| .. | ||
| README.mdx | ||
| index.hbs | ||
README.mdx
# Consul::Partition::Notifications
A Notification component specifically for Partitions. This is only a component as we currently use this in two places and if we need to add more types we can do so in one place.
We currently one have one 'remove' type due to the fact that Admin Partions can't use the default 'delete' notification as they get 'marked for deletion' instead.
```hbs preview-template
<Consul::Partition::Notifications
@type={{'remove'}}
/>
```
## See
- [Template Source Code](./index.hbs)
---