This makes it so that the authoritative holder
of all emoji data is emoji.js, and all our
UI components that need emoji data consistently
pull data from emoji.js as needed.
Or to put it another way, we no longer need the
dispatch module to know that emoji_picker is
coupled to emoji precisely by the active_realm_emojis
data; it can now make fewer assumptions.
With update_emojis, it is pretty easy
to set up the tests with reasonable
data without reaching into internal
data structures.
Also, we can begin the process of
sharing the same data with our
dispatch tests (upcoming).
Fixes#15904.
settings is supposed to be a proper OneLogin_Saml2_Settings object,
rather than an empty dictionary. This bug wasn't easy to spot because
the codepath that causes this to demonstrate runs only if the
SAMLResponse contains encrypted assertions.
Added order_by("id") clause in query for RealmAuditLog
for consistent output.
It was causing zerver.tests.test_audit_log.TestRealmAuditLog
to fail due to order mismatch.
We want to undo overrides in reverse order,
which is important if you override the
same name more than once in the same
function.
Until today the code basically prevented
us from ever using the original implementation
of a name we stubbed, and most of them start
as undefined due to their parent modules
starting with `set_global`.
But I do want this proper, and I introduced
a tiny pitfall today.
There was only one place where we weren't
overriding a function, and the use case there
was fairly unique.
Knowing that we're dealing with only functions
will simplify override and allow us to add
features like detecting spurious stubs.
This forces us to more explicitly document at the
top of the file what dependencies we are stubbing,
plus it's less magical.
Also, we may want to do occasional audits of
set_global to clean up places where we mock
things like stream_data, which are probably just
easier to use the real version of now that we
have cleaner APIs to set up stream data.
The modules most affected by this change are our
dispatch-oriented tests--basically, all the
modules that test handling of Zulip events
plus hotkey.js.
Before we were making it impossible to reuse
the function again (so we were preventing
leaks), but it's fine to just restore the
original function, especially now that some
of our tests have grown bigger.
Steve Howell
Priyank Patel
Mateusz Mandera
palash
Anders Kaseorg
Vishnu KS
Alex Vandiver