@@ -859,32 +859,21 @@ class Entity(Endpoint):
859859
860860 ``Entity`` provides the majority of functionality required by entities.
861861 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 .
864864
865865 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']
881871
882872 You can also access the fields as though they were the fields of a Python
883873 object, as in::
884874
885- ent.email.action
886- ent.disabled
887- ent.whitelist
875+ ent.alert_type
876+ ent.search
888877
889878 However, because some of the field names are not valid Python identifiers,
890879 the dictionary-like syntax is preferable.
0 commit comments