Some of our admin prefer to not default to getting a notification when something is closed. I realize this is probably happening because of the comment that is made on the ticket, but it’d be nice to be able to turn off the notification for this particular state change. It’s a bit of friction for our flow (like when someone is approved, all other approvers have to clear the activity on each of them even though we’ve already gone through our two approvals, etc).
Thanks for the suggestion. I’m not sure, though, if you mean just the “Unread” indicator, or the actual notifications that show up when you log in and are viewed via the
notices command (or the bell icon on web).
Notifications are for your personal attention, and you should only receive notifications for jobs you’ve handled.
If you mean the unread marker, I’m afraid that’s a core part of the jobs system that’s not really feasible to change for this specific case. New activity (which includes all comments and status changes) marks a job unread, to facilitate communication amongst staffers. For instance, if Bob the closes out a plot job, the other plot staffers likely need to know about the resolution so everyone can be on the same page.
You don’t really need to mark jobs read though. You could use other filters like “Mine” to only see your own jobs, or “Unfinished” to ignore all the closed jobs.
Sorry. Yeah I mean the unread notifier in the jobs filters.
Actually, we do need to mark things as read to get them off of mine. I’m going to check these scenarios on the latest versions (we skipped two to latest)…there might be something broken. I’ll reply here with results.
Here’s my problems:
- This produces a lot of noise and causes people a lot of headaches - Our admin culture is predicated on trust. We already do a lot of work to align ourselves and do it naturally bc we are a small game.
- There is no filtering to do this based on things that matter to people (role access seemingly but not fully tested, people who have commented on a ticket, people who have handled the ticket at one point in time, people who are participants). I should be able to add the right participants because I’m a responsible staffer.
I don’t like the culture this encourages. It’s mistrustful, especially when anyone can go back and look at closed tickets and there’s already an archival expiry to make it easy for them to do so (it’s already transparent). I just think there are better ways of handling this. And if there aren’t, I’d like the option to do so.
The “MINE” filter should not show unread jobs that aren’t assigned to you. The code is simply “assigned to me + open”. I can check that out further if you think it’s broken, but it looks OK to me.
It’s not really about trust it’s just about information. Transparency. Everyone can see what everyone else is doing to keep everyone in the loop.
That said, Ares is fully extensible, and games are welcome to make custom code changes if the built-in systems do not meet their needs.
If client-spam is part of your problem, in terms of the “noise,” you can mute the notifications client-side. I do this on BeipMU 'cause I almost always reply to jobs on the portal while logged in to the client, and I don’t like it to flashy me.
You could modify it to gag all job notifications.
Here are a few workflows that are not dependent on the ‘unread’ flag for looking through jobs.
- Use the ‘Mine’ filter to see just the jobs you’re handling.
- Use the ‘Unfinished’ filter to see any jobs that aren’t completed yet.
- A game can define its own custom status filter to see jobs that are in particular statuses, like a ‘todo’ filter that finds jobs in new or hold.
You can use
jobs/catchup to clear all unread job indicators. If you rely on notifications for the jobs you’re personally handling, you can even add this to your
onconnect and then never have to worry about it.
I did realize as I was testing that there’s no ‘catchup’ button on the web portal jobs page, which is just an oversight. I can add that. Also thought it would be handy to have an ‘unassigned’ filter to see ones that haven’t been handled yet, so I’ll add that too.
Hope that helps. The system doesn’t do everything for everybody, but there is a lot flexibility built in.
Okay. I’ll make sure if I see something that feels weird, I check it against this design spec. Thanks for spelling it out explicitly for me Faraday, and thanks for the tip Karma, but the emit spam is not my issue.