@@ -859,32 +859,21 @@ class Entity(Endpoint):
859
859
860
860
``Entity`` provides the majority of functionality required by entities.
861
861
Subclasses only implement the special cases for individual entities.
862
- For example for deployment serverclasses , the subclass makes whitelists and
863
- blacklists into Python lists .
862
+ For example for saved searches , the subclass makes fields like ``action.email``,
863
+ ``alert_type``, and ``search`` available .
864
864
865
865
An ``Entity`` is addressed like a dictionary, with a few extensions,
866
- so the following all work::
867
-
868
- ent['email.action']
869
- ent['disabled']
870
- ent['whitelist']
871
-
872
- Many endpoints have values that share a prefix, such as
873
- ``email.to``, ``email.action``, and ``email.subject``. You can extract
874
- the whole fields, or use the key ``email`` to get a dictionary of
875
- all the subelements. That is, ``ent['email']`` returns a
876
- dictionary with the keys ``to``, ``action``, ``subject``, and so on. If
877
- there are multiple levels of dots, each level is made into a
878
- subdictionary, so ``email.body.salutation`` can be accessed at
879
- ``ent['email']['body']['salutation']`` or
880
- ``ent['email.body.salutation']``.
866
+ so the following all work, for example in saved searches::
867
+
868
+ ent['action.email']
869
+ ent['alert_type']
870
+ ent['search']
881
871
882
872
You can also access the fields as though they were the fields of a Python
883
873
object, as in::
884
874
885
- ent.email.action
886
- ent.disabled
887
- ent.whitelist
875
+ ent.alert_type
876
+ ent.search
888
877
889
878
However, because some of the field names are not valid Python identifiers,
890
879
the dictionary-like syntax is preferable.
0 commit comments