Tags act as a shared labelling scheme across a team, but they are only ever suggested to people who can read the event definition the tag came from. A colleague can see a tag sitting on an event, and still find it in no suggestion list anywhere, so they have to retype it exactly from memory or invent their own.
Repro
- Create user A with the
Event Definition Creator role, with view access to the Default Stream.
- Create user B with the
App Owner role, also with view access to the Default Stream.
- As user A, create an event definition on the Default Stream with a distinctive tag, for example
shared-vocab-tag, and wait for it to fire.
Now log in as user B, who can see the events but cannot read user A's definition.
- Go to Alerts & Events. The fired events show
shared-vocab-tag in the Tags column.
- Click Filters > + > Tags.
shared-vocab-tag is offered, and filtering by it returns the expected events.
- Go to Alerts > Event Definitions > Create event definition, open the Additional Details step, and start typing
shared- in the Tags field.
- Go to Alerts > Event Definitions and click Filters > + > Tags.
Observed
At steps 4 and 5, user B sees the tag on the events and can filter events by it.
At step 6 no suggestion appears for shared-vocab-tag. To apply the same tag to their own definition, user B has to already know it exists and type it character for character.
At step 7 the Tags filter on the Event Definitions page offers no values.
If user B types shared-vocab-tag by hand on their own event definition, everything behaves correctly from then on.
Note also that once user B owns a definition carrying the tag, it is offered to them in the suggestions. The effect is that the suggestion list can only show a user the tags they are already using, which are the ones they least need to be reminded of.
The gate is read access to the event definition, and nothing else:
Why this matters
The value of tags is consistency. If the existing vocabulary is invisible to everyone except the people who can read each definition, teams drift into near duplicates such as brute-force, bruteforce and brute_force. Filters and groupings then quietly miss events, because nothing warns you that a very similar tag already exists.
Step 5 versus steps 6 and 7 is the part that is hardest to explain to a user: the same tag, for the same user, is offered by one filter and absent from another.
Product Question
Is scoping tag suggestions to the definitions a user can read intended behaviour? The tags themselves are already visible to anyone with access to the events, so leaving them out of the suggestion lists does not appear to keep anything confidential, while it does make consistent tagging hard for everyone but the definition's author.
Version: Graylog 7.2.0-beta.1
Tags act as a shared labelling scheme across a team, but they are only ever suggested to people who can read the event definition the tag came from. A colleague can see a tag sitting on an event, and still find it in no suggestion list anywhere, so they have to retype it exactly from memory or invent their own.
Repro
Event Definition Creatorrole, with view access to the Default Stream.App Ownerrole, also with view access to the Default Stream.shared-vocab-tag, and wait for it to fire.Now log in as user B, who can see the events but cannot read user A's definition.
shared-vocab-tagin the Tags column.shared-vocab-tagis offered, and filtering by it returns the expected events.shared-in the Tags field.Observed
At steps 4 and 5, user B sees the tag on the events and can filter events by it.
At step 6 no suggestion appears for
shared-vocab-tag. To apply the same tag to their own definition, user B has to already know it exists and type it character for character.At step 7 the Tags filter on the Event Definitions page offers no values.
If user B types
shared-vocab-tagby hand on their own event definition, everything behaves correctly from then on.Note also that once user B owns a definition carrying the tag, it is offered to them in the suggestions. The effect is that the suggestion list can only show a user the tags they are already using, which are the ones they least need to be reminded of.
The gate is read access to the event definition, and nothing else:
Why this matters
The value of tags is consistency. If the existing vocabulary is invisible to everyone except the people who can read each definition, teams drift into near duplicates such as
brute-force,bruteforceandbrute_force. Filters and groupings then quietly miss events, because nothing warns you that a very similar tag already exists.Step 5 versus steps 6 and 7 is the part that is hardest to explain to a user: the same tag, for the same user, is offered by one filter and absent from another.
Product Question
Is scoping tag suggestions to the definitions a user can read intended behaviour? The tags themselves are already visible to anyone with access to the events, so leaving them out of the suggestion lists does not appear to keep anything confidential, while it does make consistent tagging hard for everyone but the definition's author.
Version: Graylog 7.2.0-beta.1