This question is mainly directed at @Lucas_Pires and/or @Robert_Petitto, but if anyone else has any advice I’ll be all ears 
A couple of months ago, I built a prototype for doing Global Announcements. I did it because it was something I knew I’d be needing sooner or later for one of my apps. I now need to implement it, and I’ve been thinking over my approach for a week or two, and procrastinating, mainly because I’m not really sure that the approach I have in mind is sound. So I guess I’m seeking a bit of validation.
From my earlier post, my requirements are:
- An Administrator can create an announcement and target it at a specific group of users
- When a user opens the app, any new announcements will be front and centre on their dashboard
- The user can view the announcement and mark it as read
- Administrators can track how many users have read each announcement, and which users
I need to expand a little on the first requirement…
Users of this app can be categorised in two ways:
- By Division. Each user belongs to a division, and divisions have names such as Sales, Operations, Marketing, etc.
- By Employee Type. This is a little more obscure, but the important point is that every user will have an employee type
Currently, we have 7 employee types and 12 divisions - but those numbers could change. And this is where the challenge comes in (and where I think I need to use an extra bit of trebuchet magic).
When an administrator creates an announcement, he needs to be able to target that announcement at any combination of employee type and/or division. For example:
- Announcement A
- Goes to Sales, Marketing and all employee types in those two divisions
- Announcement B
- Goes to all divisions, but only employee types X, Y & Z within each division
- Announcement C
- Goes to all divisions and all employee types (everyone)
In coming up with a solution, I have two main goals:
- Each Announcement should only occupy a single row, including the tracking of which users have read the announcement (ie. trebuchet to the rescue)
- The solution should be easy(ish) to maintain, and should be easily extendable in the case that the number of Divisions and/or Employee Types changes in the future.
A simple brute force approach would be to just add a bunch of boolean columns to my Announcements table - one for each division, and one for each employee type - and be done with it. But I really don’t like that, and I think it would be much more elegant (and way cooler 
) to store the target employee type and division in a single column each, using trebuchet.
But I’m a bit worried that once I start down this path I could end up tying myself in knots trying to implement it and wind up with a huge mess. In particular, I’m struggling to visualise how I would handle “add/remove all items in the list” using trebuchet.
So, my question: is this a good use case for trebuchet, or should I just take the easy way out? 
PS. If it is a good use case for trebuchet, any implementation tips would be extremely welcome 
)