DigitalOcean logs just have a "User" column and it has your own user, system, and sometimes distinguishes it with other parts of the system.

I will add initiator_name to the payload response for the api to use

#2174 adds the initiator_name to the API calls. FE still needs an update

Should we add a system user? Without a special user in the database, and foreign key relations will not work. So the field will have to be null for the intiator_id? And we'd treat null special?

Does anyone oppose adding a system user much like Github's Ghost user?

I'm a fan of this.

I'm uncertain whether having it in the database is best, or making it a static UUID instead like reserving uuid.Nil is safer.

@kylecarbs I was thinking a special uuid, but if we have foreign key relations setup, we will need a row in the db to satisfy constraints.

I imagine we'd do both. Use a special uuid, and insert into the db.

@kylecarbs @Emyrk Just wanted to reach a decision on the discussion here. Considering the foreign key behavior of initiator_id, we might need a db reference, unless we handle the null value in code. I wonder if the field should be nullable or not - personally, I'd prefer it to be non-null.

I'd also prefer non-null.

Keep it non-null. I'm curious if we ever need to distinguish between initiated_by being system and autostart. Or something akin to that. I don't want to populate the db with a bunch of random system users. Maybe just system is enough for now...

Would be nice to know it started because of autostart though, rather than the vague system.

I understand if it is really out there, but I'd love for it to be named coderbot. 😂 Not sure if autostart is a good name for the stop action, would prefer something more generic.

autostart was not a good suggestion, you are correct. Maybe scheduler or something idk. Regardless, that would either require 2 system users, or some sort of meta data field to elaborate the system user. (w/e that system user's name is, idc)

I like both coderbot and scheduler. The latter has more specificity, although maybe we need to put that information in a different column (reason?) rather than relying on the name, and we still might need to call it coder-scheduler or something. And perhaps highlight system users in a different color.

The column name in the UI can be called Initiated by which should alleviate the need to use a different column imo. We can add the highlighting to indicate it is a system user for sure.

The separate column idea, which is totally optional right now, is because we might have multiple reasons to perform a particular action. For instance, a workspace could get (re)started or built as part of administrators forcing all workspaces to update the project.

That makes sense. This looks like a separate issue of its own though. I wonder if we'd wanna figure out the reasons ourselves, or let admins/users input their reasons when taking the action. In case we end up always assigning the same reason when the initiator is the same, it would seem moot to add the column.

Yep, can be separate.

system is the name I usually see used for these kinds of operations. If we wanted to delineate the subsystem perhaps we could use an actor like system/scheduler.

I also like the idea of coloring this user differently when it appears in the UI.

+1 on "system" and +1000 on different color

@ketang I filed #2410 for discussion on the reason column.

@ammario I like system/scheduler.

#2428 adds a system user with a special uuid.