Skip to content
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

Merged
merged 4 commits into from
Dec 6, 2018
Merged

Add user.full_name #201

merged 4 commits into from
Dec 6, 2018

Conversation

webmat
Copy link
Contributor

@webmat webmat commented Nov 30, 2018

To be populated when a full name is available.


The field is a keyword, and will not be tokenized.
- name: full_name
Copy link
Contributor

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.

Copy link
Contributor Author

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 name
  • user.full_name (or equivalent) for human name
  • user.name for full name
  • user.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.

Copy link
Contributor

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 ...).

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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?

@webmat webmat merged commit 9329a21 into elastic:master Dec 6, 2018
@webmat webmat deleted the user.full branch December 6, 2018 15:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants