Cachet: display author name of post

[davidak]

We are a small team of admins and use Cachet to inform other collegues internally.

It would be nice to have the option to enable (in the settings) to see the user who posted an entry. (i hope you already save that in the database)

Our current workaround is to just put it in the text.

[jbrooksuk]

Feel free to pick this up. It's something that would go into the Theme settings.

[MatthewSH]

@jbrooksuk We'll have to re-add the user_id column that was dropped in 2015.

We can add the user_id column, index it, and have a foreign key reference to id on users.

Adding onto that, we could create a route that shows all the incidents reports by a user. Such as example.com/author/1.

I could probably do this in my spare time.

[jbrooksuk]

Cool, I look forward to seeing your PR :)

[GrahamCampbell]

What happens if the user later deletes their accunt

[ConnorVG]

We'd just have to use soft-deletable users, if we want to keep their blame.

[MatthewSH]

@GrahamCampbell @ConnorVG or we could just have a check to see if the user model is null, if it is then don't display it at all.

[ConnorVG]

@MatthewSH that seems pretty hacky :disappointed:

Soft deletes or a specific fallback account would be best, IMO.

[MatthewSH]

@ConnorVG true, however...it may be the easiest way to approach the situation without modifying too much that's already there. Really it's simple in the view...

@if(author)
Posted on *date here* by {{ author->name }}
@else
Posted on *date here*
@endif

[ConnorVG]

@MatthewSH Having those checks in anything that we decide to add blame too when we could instead just handle it at the source of the problem seems very roundabout to me.

Is there anything specifically off-putting about soft deletes to you?

[MatthewSH]

@ConnorVG not really, I'm just trying to not update too much with it. However, even with soft deleting, won't the find method still come back null? We would still have to include some form of a check for that, and still check to see if the model is null anyway.

We could always fall back on an id 0 (or -1) user we could seed in at the start. However, the question is...what would we name them? Cachet? System?

[ConnorVG]

When querying for blame we can always just append ->withTrashed(). Blame could be treat this way specifically.

Though, all that said, I'm unsure if @GrahamCampbell or @jbrooksuk would want it this way (soft deletes).

[MatthewSH]

@ConnorVG that's why I'm considering the other way, to avoid changing some of that functionality. I would rather, personally, only change things that are absolutely needed for the PR.

[ConnorVG]

@MatthewSH it's generally a good idea to do minimal PR changes but this feels like something that would easily integrate with other parts of the system (when it comes to blame) so I think it should take more thought. IMO, anyway.

[MatthewSH]

@ConnorVG that's why I'm throwing out some options before I start on it ;)
Just waiting for @GrahamCampbell and @jbrooksuk to come back and give their thoughts.

[jbrooksuk]

I have nothing against soft deleting users. We don't really have a choice if we were to have this kind of archival data anyway.

[MatthewSH]

Sorry, just got back from work.

Okay so now @jbrooksuk and @ConnorVG the question remains.
I assume although we include the trashed authors for the incidents, we don't want them to have their own page?

Also, any thoughts on the author page design? I'm thinking a simple design similar to how incidents are displayed on the main page, but the top section being modified a bit to include the avatar and name.

[davidak]

@MatthewSH thanks for your initiative!

I wouldn't include the avatar in the post. the author in blogs or newspapers has also no avatar since the important part is the post, not the person who published it. only the name should be displayed so you can look who published it when you are interested.

Also i know from systems like JIRA or some forums that they display "Deleted user" if the user don't exists anymore. I think that would be fine here. But displaying the name after a user was deleted would be also fine.

[jbrooksuk]

I assume although we include the trashed authors for the incidents, we don't want them to have their own page?

They'd still need their own page for archival reasons.

Also, any thoughts on the author page design? I'm thinking a simple design similar to how incidents are displayed on the main page, but the top section being modified a bit to include the avatar and name.

Well, the design is currently undergoing a big overhaul, so I wouldn't worry. Just get the info printed and we'll add the new design when it's ready.

Also i know from systems like JIRA or some forums that they display "Deleted user" if the user don't exists anymore. I think that would be fine here. But displaying the name after a user was deleted would be also fine.

Maybe we could display that in a badge or something next to the name.

[jbrooksuk]

Remember, this should be an optional setting.

[MikeKMiller]

Just to throw something out there.... Soft Deletes will cause issues with certain regulators in some industries. Just like simply disabling users accounts on a network, but not ever deleting is a major no-no. In addition if you had a user that requested their account be removed, but really wasn't is another potential headache.

[MatthewSH]

@mm-manageit I understand where you're coming from there. This isn't a software that I can see having that issue, however. Really, though, if someone asks you to delete their account. Even with soft deleting, it is deleted to the software itself, unless of course you call them that is. I think that for instances like that, you should put something in your terms of service stating that deleting an account with remove all the associated data and will disable the account, but not remove it entirely from the database.

I personally like soft deleting more because it's archiving data, and if I need to see lifetime data (including archived data) I can pull it like that. I had a software one time that did exactly that. Once the row's data was used it was removed. This becomes a problem when I wanted to see a history when people were abusing my software. Having soft deleting would've helped. I wasn't using Laravel keep that in mind.

By the way, I've had like no time this month to work on this. It's fallen low on my priority list as you can imagine. Sadly.

[jbrooksuk]

Just to throw something out there.... Soft Deletes will cause issues with certain regulators in some industries. Just like simply disabling users accounts on a network, but not ever deleting is a major no-no. In addition if you had a user that requested their account be removed, but really wasn't is another potential headache.

Good point. One way around this would be for us to create a cachet:archive command which permanently deletes all soft-deleted data. We'd have to allow for configuring the frequency of this, but that's no biggie.

[jbrooksuk]

I noticed this is a duplicate of https://github.com/CachetHQ/Cachet/issues/2097