You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is asking for changes to how profile details are presented, and to add an annotation for profile-specific attributes to class and object detail pages.
Presentation of profile details
There are two special-case ways to use profiles are are not shown on the OCSF server in any way:
Attributes of classes and objects can be directly included in a profile without adding it to the profile itself. This allows class-specific / object-specific attributes without affecting all other uses of the profile. As of this writing, the only active use in the core schema is in the resource_details object that adds two attributes for the cloud profile without affecting all other uses, including Base Event itself (which can use the cloud profile).
Attributes of a classes and objects can use "profile": null to indicate that an attribute that would otherwise be part of a profile should always be enabled.
Neither of these cases are presented in any way on the OCSF Server.
For case 1, we want to include these class/object specific cases on the detail page for the profile (such as /profiles/cloud). This can be a separate section after the main attributes table.
For case 2, as if this writing I'm unsure about how to present this. More thought is needed. Maybe it's not necessary. Maybe it should be shown on the class and object detail pages. Maybe something else?
Presentation of profile-specific attributes on class and object detail pages
At the moment, when a profile is checked on a class and object detail pages, the profile's attributes are added to the attribute list. However because there are typically quite a few attributes listed on these pages, it can be hard to see which attributes are for the enabled profile.
The annotation should also differentiate between attributes that are defined in the profile itself and those attributes that are added (or modified?) in a specific class or object.
Consider modifying the tooltip popup for class and object attributes (hovering over the "Name" column) to show profile details: if an attribute is from a profile, and the profile name.
We want to add a profile annotations for attributes, similar to what we do for extensions. This could be confusing, so we may want to reconsider how how extensions are annotated as well so both are presented clearly. There are cases where an attribute will be both an extension and profile, and so would have both annotations, and further there are cases like the Linux profile, which can use the same name for both the extension and profile. So, whatever mechanism is used, it should be clear that the annotation refers to a profile or an extension.
The text was updated successfully, but these errors were encountered:
This issue is asking for changes to how profile details are presented, and to add an annotation for profile-specific attributes to class and object detail pages.
Presentation of profile details
There are two special-case ways to use profiles are are not shown on the OCSF server in any way:
resource_details
object that adds two attributes for thecloud
profile without affecting all other uses, including Base Event itself (which can use thecloud
profile)."profile": null
to indicate that an attribute that would otherwise be part of a profile should always be enabled.Neither of these cases are presented in any way on the OCSF Server.
For case 1, we want to include these class/object specific cases on the detail page for the profile (such as
/profiles/cloud
). This can be a separate section after the main attributes table.For case 2, as if this writing I'm unsure about how to present this. More thought is needed. Maybe it's not necessary. Maybe it should be shown on the class and object detail pages. Maybe something else?
Presentation of profile-specific attributes on class and object detail pages
At the moment, when a profile is checked on a class and object detail pages, the profile's attributes are added to the attribute list. However because there are typically quite a few attributes listed on these pages, it can be hard to see which attributes are for the enabled profile.
The annotation should also differentiate between attributes that are defined in the profile itself and those attributes that are added (or modified?) in a specific class or object.
Consider modifying the tooltip popup for class and object attributes (hovering over the "Name" column) to show profile details: if an attribute is from a profile, and the profile name.
We want to add a profile annotations for attributes, similar to what we do for extensions. This could be confusing, so we may want to reconsider how how extensions are annotated as well so both are presented clearly. There are cases where an attribute will be both an extension and profile, and so would have both annotations, and further there are cases like the
Linux
profile, which can use the same name for both the extension and profile. So, whatever mechanism is used, it should be clear that the annotation refers to a profile or an extension.The text was updated successfully, but these errors were encountered: