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