-
Notifications
You must be signed in to change notification settings - Fork 431
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add user.full_name #201
Add user.full_name #201
Conversation
|
||
The field is a keyword, and will not be tokenized. | ||
- name: full_name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I initially hoped that user.name
is what accounts for both of these. But I see that's not necessarily the case. Do we need full_name
in ECS?
In most other cases *.name
is the user defined part. With the above we change the logic here a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I absolutely think we need both fields, otherwise we'll have the typical aggregation problem: when aggregating on names, the users for who we have both a login name and a full name will appear twice. In most logging use cases we only get programmatic use case, but in user management auditing, or when enriching all logs with all available scenarios, this will be a very common field to add to users.
Now we could have gone both ways to introduce duality of programmatic and human name:
user.name
for programmatic nameuser.full_name
(or equivalent) for human name
user.name
for full nameuser.login
(or equivalent) for programmatic name
I decided to go with 1) because programmatic name is by far the most commonly seen, and therefore we're already using user.name
as programmatic name everywhere. So the addition as I'm proposing it is not a breaking change, which is a big plus. Also, since the programmatic name is the most commonly seen, might as well make this field the shortest, most canonical one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My proposal is to go with 1
but specify user.name broader. It does not have to be the programmatic one but can also be a user specified one. full_name
in contrast is very specific and from my perspective means firstname
+ lastname
(not sure about order and middle names ...).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would never recommend being specific on the content of a full name. It is indeed going to be different from my expectations in some cultures. People should enter whatever makes sense to them in there.
However if we instruct people to add both names in the same fields, all events that have a full name specified in addition to the programmatic name will appear twice in aggregations. I don't think it's a good idea to go in that direction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's just soften up logic / programmatic name phrasing a bit in the description, then I'm good to go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated. Does Short name or login of the user.
work?
To be populated when a full name is available.