toplevel-property-extension style extensions. If an unregistered
extension of that type is encountered, all unrecognized toplevel
props will now be considered extension properties (not custom).
It will no longer turn on the allow_custom flag, which would
allow customizations everywhere.
Also, if all extensions of the aforementioned type are registered,
their properties are now used to properly distinguish between
extension and custom properties. There need not be any ambiguity
in that case.
fixes.
- Fixed bugged logic in _STIXBase._check_at_least_one_property(),
and revamped the code to be simpler and clearer.
- Changed custom extension registration to auto-create an
"extension_type" property based on the attribute of that
name on the custom class, if present.
- The custom extension registration change above uncovered
what seemed like a bug in a unit test: a custom extension
was registered, but it was not given an extension type. The
test used the extension as extension_type="property-extension";
this now causes a standard error about an extra property. I
fixed the test to assign the custom extension the proper type.
- Changed an error message "Cannot determine extension type."
At that point in the code, we in fact have a registered
extension type and the class for it, so it didn't seem to make
any sense. I changed it to say that an extension of that type
couldn't be created from type of value given. Because this is
really about typing (in both the old and new code), I also
changed the exception class to TypeError.
- Changed customization behavior: unregistered
"extension-definition--" style extensions are no longer
considered custom. Their mere presence can no longer be
considered a customization, since it doesn't fit the
criteria, and in fact the extension mechanism is supposed to
supplant the old customization system anyway. Unregistered
extensions of other types are still considered custom.
- Fixed up unit tests according to the exception message
change.
- Added a unit test for unregistered "extension-definition--"
style extensions.
The "loophole" occurs when an object contains an unregistered top-level
extension. Since it's unregistered we can't tell if any custom
properties on the object were defined in that extension so we assume
that they are.
properties are now always accepted and not considered
customizations (has_custom will be False). Just commented out
the enforcement code and xfail'd the unit tests, which makes it
easy to reinstate these behaviors later. It was decided this
is too likely to break user code, and we don't currently have
a way to disallow customizations in other places while still
allowing custom open vocab values. Safest to always allow
custom open vocab values, for now.
objects, to structure object_refs type requirements as an empty
blacklist, instead of a whitelist. I think it was originally
necessary due to the older implementation of ReferenceProperty
which was in place at the time. With the implementation change
to invert whitelists with generics to blacklists when
allow_custom=True, a "full" whitelist is internally converted to
an empty blacklist anyway, so it winds up being the same thing.
But I think the full whitelist looks better in the code, so I
prefer that to the empty blacklist.
available after the rebase. This simplifies the implementation.
Also made utils.to_enum() a module public function, since I
needed to use it outside that module. Misc pre-commit stylistic
fixes.
constraints (i.e. both generic type categories and specific
types). Also:
- more expansion/refinement of reference property unit tests
- bugfix: SROs are in OBJ_MAP too, it's not just SDOs! Oops...
- pre-commit stylistic fixes
assert prop.clean(...)
doesn't test well enough since clean() methods on this branch
produce 2-tuples, and you should test what's in the tuple, not
just that it returned something non-empty. So I fixed it in
several places to test the tuple contents.
work when a whitelist of generic category types is used.
Disallow hybrid constraints (both generic and specific at the
same time). Add more unit tests.
thought it should, but forgot to fix Report to use
ReferenceProperty in the way I thought it should! Oops.
Added some tests to ensure Report is working property with
custom ID types in object_refs.
Michael Chisholm