Story template

## Background

<!--
Explain any background or assumed knowledge to understand this story. A couple sentences usually.
This is also a good section to clarify the usage of terms that others may not know but will be used to describe
this request.
-->

## Desired Behavior

<!--
Explain what you would like to see. When I go to X, I want to see A, B, and not C.

Words are more important here than a screenshot. Screenshots can often lead to more questions than they are worth
because they are too broad (more context than is needed) or outdated from the site. This means that in a few weeks
time, they no longer make sense as the app has changed.
-->

## Business Case / Why? / ROI

<!--
Why are we doing this over another task?
If unsure, it is better to remove this section than exagurate a requests importance.
This will help the team challenge if this story is more or less important to prioritize against others being considered.
-->

## Acceptance Criteria

<!--
Call out what you expect to check when it comes time to QA this feature.
This list should also include things non-development related. Often this can be notifying the requesting customer
of the fix or updating documentation.
If something is missing in QA, it will often result then in a new feature request.
Using a check-list here, will make sure things have been verified versus getting missed when it's a bullet-list.
-->

- [ ] When adding A, B, and C. The admin can see all of these.
- [ ] When adding A, B, and C. The viewer can only see C as it has been approved.
- [ ] Notify {customer} that the fix was shipped.
- [ ] Update Wiki relating to this feature.
- [ ] Update documentation

## Developer Notes

<!--
To be filled in by developers to help accelerate or clarify the above.
Things like where to find code to copy or start with, or translation of terms between the above.
-->