Add DARIA admin panel view

[colinxfleming]

Thanks for creating an issue! Please fill out this form so we can be sure to have all the information we need, and to minimize back and forth.

• What are we trying to do?

A suggested enhancement from our report:

While DARIA currently implements logging of actions taken by users, there is no way to view the logs without opening log files located on the server. This may be beyond the technical skill of most users and administrators, unless they have a technical background in system administration. DCAF should strongly consider adding an interface to the DARIA web application that allows administrators to easily view and search logs.

Additionally, DARIA should include a mechanism for sending automated alerts to instance administrators for certain security-related events. Such events may include a user getting locked out from too many failed login attempts, a user logging in from an IP address outside of the country, new user accounts being added (especially with admin privileges), password resets, data deletion, etc.

They're right, we should do this. Here's my proposal:

• Make a list of events that require tracking within DARIA and divide them into notices and warnings
• An Event-style log that tracks all events within DARIA
• Send emails to admins on warnings

We have a searchable log system (logentries) that is accessible to engineers, but I'm not sure there's any utility to making it admin ready. @alisonnjones should holler if that's not the case and she wants to see the guts.

• What feature or behavior is this required for?

Security notices

• How could we solve this issue? (Not knowing is okay!)

Do stuff above

• Anything else?

Via our security audit

[colinxfleming]

@valeriecodes this is something that I've been meaning to do for awhile that I think would be a great security and administration value-add, if you've got interest and capacity. If it sounds good or interesting to you, lmk!

[valeriecodes]

YES!

[colinxfleming]

❗️
so if left to my own devices, I would implement something along the lines of this:

• a new page
• can hook up the actual events into our existing event model and having it include some other stuff, though you'll probably want to add a new type of event.
• the simplest event to make is probably new user being added -- let's start with that and then see about adding the other stuff.
• our existing event stuff works by model callback. see the concern EventLoggable for how it works now. Use this if it feels easy but if this gets awkward feel free to do whatever feels right.
• gold medal version: filter and sort events maybe? if we want to get really buckwild?

I don't think I have an opinion on what this should look like, so you can do it as simple or complex as you like. Does this feel like good runway, anything I can do to get you off on the right foot here? Would you like me to break this into component tickets?

[valeriecodes]

Hi @colinxfleming, took a closer look at this one today. I also noticed the AuditTrail, which could also potentially be used for the created user use case, but in the interest of extensibility I assume it's preferable to take the events approach?

[colinxfleming]

@valeriecodes I could def be convinced that we could do this all with audittrail. Down the line we're going to care about stuff like privilege escalations, logins, etc, and maybe some other stuff outside the user model Events as its own model felt like the most straightforward way to do that when we were setting up the CM activity feed, but if AuditTrail works out of the box without having to write too much additional code, why not, right?

The nut of this question might be 'how easy is it to query and parse audit trail records for some particular condition', 'how easy is it to categorize them by type', and 'how easy is it to shuffle in Event objects'. Those are basically the problems that the Event model is solving, so if the answer to those questions is 'easy as hell' then maybe we don't need the standalone Event model?

[colinxfleming]

I'd like to revisit this in the nearish future. Here's what I think I'd like, specifically, to start:

• a new view, /admin/
• powered by a new controller, AdminsController
• that starts by loading events from all lines, paginated (copying and pasting what we do on the main call list dashboard is fine for UX)
• and is only available to people with admin privileges
• and which is linked to in the drop-down where clinics, configs etc is.

[colinxfleming]

Did a little experimentation on this tonight:

• Our current event model is pretty rigid. We should either expand it such that params are json, or roll a new model for this. Otherwise we're doing a lot of data shoehorning / saying a CM is roughly equivalent to a patient and I'd rather not do that.
• (Other than that this still feels fairly sound to me.)

[ghost]

@colinxfleming I finished up these designs!

• Figma prototype (clickable): https://www.figma.com/proto/xqY0RFbj86P4dLXiFO0CHw/DCAF?page-id=107%3A2621&node-id=107%3A2631&viewport=241%2C48%2C0.4&scaling=scale-down-width&starting-point-node-id=107%3A2631
• Full Figma file: https://www.figma.com/file/xqY0RFbj86P4dLXiFO0CHw/DCAF?node-id=107%3A2621

A few notes:

• I tried to use Bootstrap components when I could (e.g. pagination, tags/badges)
• I didn't see a Bootstrap component for the date picker so I just found one online that I thought worked well. That said, I'm not too attached to it so if you're already using a date picker elsewhere that's already built, go for it!
• The prototype shows how I envision the filters & search working

Let me know if you have any feedback or if you want to talk through anything!
Emilia

[colinxfleming]

This is absolutely fabulous and I'm very thankful for this contribution - for sure it's making us think of stuff we wouldn't have otherwise considered that's going to be extremely useful!

I think tags as a set thing is chill, but would prefer to avoid a world where we're adding tags to events on the fly - I think adding tags when we log an event should be fine. I don't think I have any other particular critiques though, and we can 100% run with this. We also may want to figure out a way to simplify the search stuff (primarily for laziness' / expediency's sake) when we draft those tickets.

So to break this up into steps we can delegate out, I think it looks something like this:

• set up the controller, base view, and pagination (we can use the current patient events as a stub for now)
• adjust the current event model to take more info + events like these
• tie this all together and release it to funds
• do the search stuff

I will start drafting tickets shortly!

[ghost]

Awesome, thanks! Let me know if you need anything from me :)

[lomky]

@all-contributors please add @emtot22 for design

🎉

[allcontributors]

@lomky

I've put up a pull request to add @emtot22! 🎉