-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
Description
(This writeup is a work in progress and will be fleshed out more.)
We have tons of requests from folks to improve the notifications system (and a lot of work is being done on the backend to get us to a point where can do that) so I wanted to try to encapsulate the majority of the requirements that we're looking at in one place.
Common Requests:
(Also see the linked sub-issues)
-
Customizing the text of the emails. This is harder than it seems, since we support 60+ languages, so in theory, everyone's custom text would have to be translated into every language their users are using, which would require a huge amount of work and I'm just not sure that's really feasible. Not to mention that there will be confusion if there is a type or broken HTML in the admin-entered override version - troubleshooting that will be a nightmare. (Was it the default message, or the one an admin created?)
-
More selective notifications. Some folks want notifications (webhook and emails) on more actions (editing, etc.) This is pretty do-able, and dovetails into the revised logging system we've been working on for a while.
-
More options for who gets notified. This certainly makes a lot of sense, it's just pretty hairy, since everyone kinda wants something else. Some things I think are do-able would be to notify a manager of a person or location if something is checked in/checked/out, etc, if a manager exists and has an email address.
-
Override (or add) admin notifications by Company. In a multi-company setup, the Snipe-IT admin who should be notified might not be the same contact from company to company. This goes the same for webhooks. Different companies might have different slack workspaces.
-
Different webhook endpoints for different actions. Edit/checkout/etc might not all belong in the same channel.
-
Hooking alerts into webhooks. If you're less email-centric and more slack-centric, having those alerts go into a webhook instead of email (or both) could be useful. This gets a little tricky, since each webhook endpoint will have a limit of how large the payload can be, so that might take some trial and error, and we might have to compromise by only showing the first
xresults and then providing a link to the rest of the results. -
Possibly different notification rules based on whether the request came from an API. User edits via API could get very very noisy. I'm not sure this is something we'd consider implementing, but it's worth considering.
-
Possibly send selected actions to the manager in charge of the user or location to whom the item was checked out to. This feels to me like something each manager should be able to opt into, which makes this a bit more complicated. We'd have Settings rules, Company Rules, and then Manager rules. Not off the table, but pretty complicated in the longer term. We can probably get something basic going in just the settings, but that should be a short-term solution, not a long term one.
-
Being able to batch up bulk actions into fewer emails. Again, this can raise issues with email sizes with images embedded. Currently if you check out 100 things to a user at once via batch action, the user will get 100 item acceptance notifications. We've simplified the acceptance process to list pending ones, so batching that might not be as bad as it seems - although if the items have different EULAs, that gets more complicated.
Actions that should (optionally) trigger email/webhook notifications (and logs):
| Object | Action | Log | Webhook | Trigger | By | |
|---|---|---|---|---|---|---|
| Asset | Create | 🪵 | Direct Action | Admin | ||
| Asset | Edit | 🪵 | Direct Action | Admin | ||
| Asset | Checkin | 🪵 | ✉️ | ✓ | Direct Action | Admin |
| Asset | Checkout | 🪵 | ✉️ | ✓ | Direct Action | Admin |
| Asset | Delete | 🪵 | Direct Action | Admin | ||
| Asset | Restore | 🪵 | Direct Action | Admin | ||
| Asset | Audit | 🪵 | ✓ | Direct Action | Admin | |
| Asset | File Upload | 🪵 | Direct Action | Admin | ||
| Asset | File Upload Deleted | Direct Action | Admin | |||
| Asset | Due for Audit | ✉️ | Artisan | System | ||
| Asset | Due for Checkin | ✉️ | Artisan | System | ||
| Asset | Low Inventory (via Asset Model) | ✉️ | Artisan | System | ||
| Asset | Asset Requested | 🪵 | ✉️ | Direct Action | User | |
| Asset | Asset Request Canceled | 🪵 | ✉️ | Direct Action | User | |
| Asset | Asset Request Accepted | 🪵 | ✉️ | Direct Action | User | |
| Asset | Asset Request Declined | 🪵 | ✉️ | Direct Action | User | |
| AssetModel | File Upload | 🪵 | Direct Action | Admin | ||
| AssetModel | File Upload Deleted | Direct Action | Admin | |||
| Maintenancel | File Upload | 🪵 | Direct Action | Admin | ||
| Maintenance | File Upload Deleted | Direct Action | Admin | |||
| Maintenancel | Create | 🪵 | Direct Action | Admin | ||
| Maintenance | Edit | Direct Action | Admin | |||
| Maintenance | Delete | Direct Action | Admin | |||
| Accessory | Create | 🪵 | Direct Action | Admin | ||
| Accessory | Edit | 🪵 | Direct Action | Admin | ||
| Accessory | Checkin | 🪵 | ✉️ | ✓ | Direct Action | Admin |
| Accessory | Checkout | 🪵 | ✉️ | ✓ | Direct Action | Admin |
| Accessory | File Upload | 🪵 | Direct Action | Admin | ||
| Accessory | File Upload Deleted | Direct Action | Admin | |||
| Accessory | Low Inventory | ✉️ | Artisan | System | ||
| Category | File Upload | 🪵 | Direct Action | Admin | ||
| Category | File Upload Deleted | Direct Action | Admin | |||
| Component | Create | 🪵 | Direct Action | Admin | ||
| Component | Edit | 🪵 | Direct Action | Admin | ||
| Component | Checkin | 🪵 | ✉️ | ✓ | Direct Action | Admin |
| Component | Checkout | 🪵 | ✉️ | ✓ | Direct Action | Admin |
| Component | Low Inventory | ✉️ | Artisan | System | ||
| Component | File Upload | 🪵 | Direct Action | Admin | ||
| Component | File Upload Deleted | Direct Action | Admin | |||
| Consumable | Create | 🪵 | Direct Action | Admin | ||
| Consumable | Edit | 🪵 | Direct Action | Admin | ||
| Consumable | Checkout | 🪵 | ✉️ | ✓ | Direct Action | Admin |
| Consumable | File Upload | 🪵 | Direct Action | Admin | ||
| Consumable | File Upload Deleted | Direct Action | Admin | |||
| Consumable | Low Inventory | ✉️ | Artisan | System | ||
| License | Create | 🪵 | Direct Action | Admin | ||
| License | Edit | 🪵 | Direct Action | Admin | ||
| License | Checkin | 🪵 | ✉️ | ✓ | Direct Action | Admin |
| License | Checkout | 🪵 | ✉️ | ✓ | Direct Action | Admin |
| License | Delete | 🪵 | Direct Action | Admin | ||
| License | Expiring Alert | ✉️ | Artisan | System | ||
| Location | File Upload | 🪵 | Direct Action | Admin | ||
| Location | File Upload Deleted | Direct Action | Admin | |||
| User | Create | 🪵 | Direct Action | Admin | ||
| User | Edit | 🪵 | Direct Action | Admin | ||
| User | Delete | 🪵 | Direct Action | Admin | ||
| User | Restore | 🪵 | Direct Action | Admin | ||
| User | File Upload | 🪵 | Direct Action | Admin | ||
| User | File Upload Deleted | Direct Action | Admin | |||
| User | Login Attempt | 🪵 | Direct Action | User | ||
| User | Password Reset Request | ✉️ | Direct Action | User, Admin | ||
| User | Inventory Report | ✉️ | Direct Action | Admin | ||
| User | Acceptance Reminder | ✉️ | Direct Action | System |
More can (and likely should) be added, of course.
Things to Consider:
- If we do eventually allow admins to belong to more than one company, how do we handle those company-specific notifications? Without FMCS, you could have User A in Company A assigned items from Company B. With company-specific notifications, which one do we use?
Sub-issues
Metadata
Metadata
Assignees
Labels
Type
Projects
Status