-
Notifications
You must be signed in to change notification settings - Fork 28
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
Issue #63. Fix cross reference logic #64
Conversation
…ges. Before this, classes were ignored when Base Event was one of the references.
We have the 1.1 release coming up tomorrow. For the OCSF servers, we should update the docker image while we also update the schema. Are we confident that this could go into the latest docker image for the 1.1 release? |
There's no need for this with to occur with the 1.1 release. This change is independent. More broadly, I don't see a need to update the OCSF Server for the 1.1 release. It's already working properly (barring known bugs) with the 1.1.0-dev schema, as far as I know. |
Also, @mikeradka, I'm also not sure this change is desirable... See the comment above about how when "Base Event" is referenced, all event classes end are also always listed with this change. I'm not sure that makes sense.
|
Per discussion with @pagbabian-splunk, we also want to show where attributes are first included in a class or object, and where they are overridden. |
@floydtree and @pagbabian-splunk : this is ready to review |
Summary of pages changed:
Changes / things to review:
|
This is great, thanks @rmouritzen-splunk I have added inline comments for a couple of things, here are the general ones -
These are all awesome, so much cleaner and informative output.
Can you elaborate on what "Updated In" means? If we take the following as an example, I want to understand the distinction between referenced by vs updated in.
Can we make the |
"Update in" here means that an attribute's details have changed. This is typically the description field, or additional enum values.This comes from the attribute's
|
I was figuring that these lists are at the end of the page, so having a long list there wouldn't be a problem. It's easy enough to make it collapsible though. I made the change. It's only on the object and profile pages (the pages for a specific object and specific profile). Check it out. I'm up in the air about it. |
I think the change looks good, the constraints are pulled up and visible by default as well. |
Issue #63. Fix cross reference logic. This logic is used the following pages: dictionary, objects, object detail, profiles, and profile detail. Before this, classes were ignored when Base Event was one of the references. This was presumably done because when Base Event is referenced, it implies all other classes are also referenced.
The prior behavior was that when "Base Event" was a reference, no other classes were shown. With this change, the entire list of classes is shown when Base Event is a reference because, of course, anything that is in Base Event is also in every other class.
The question is: is this helpful? Is showing all classes helpful when Base Event is the one of the references?
Perhaps what we want instead is to show which classes or objects add or override an attribute. Let me know.
(The remainder of this description contains relatively minor details.)
The references are the form, with the 3 sections existing when applicable:
Now that Base Event will also appear in the classes section, the naming of event classes now consistently takes the form "Foo Class" instead of "Foo Event". This prevents an awkward "Base Event Event" name. In addition the form "Foo Class" is consistent with the class page, which uses the form "Foo (42) Class" where "Foo" is the class name and "(42)" is the class ID in parenthesis.
Listing "Base Event Class" at the top is redundant, however it does highlight when then Base Event is a reference.