In preparation for the upcoming linter output update, each custom
linter now has a identifier argument. This would be used for separating
each line of lints, eg:
py | Missing space around "%" at analytics/views.py line 485:
py | output += '<hr>%s\n'%(string_id,)
css | 64c64,65
css | < opacity: 1; }
css | ---
css | > opacity: 1;
css | > }
css | static/styles/lightbox.css seems to be broken:
swagger | In static/swagger/zulip.yaml:
swagger | Duplicate operationId: registerQueue
For performance reasons, we spawn each linter in a separate OS thread.
The downside of this is that all lints would end up in stdout without
much visual separation, resulting in confusing error log. This commit
introduce the `print_err` function, which shows which linter each line
of lint is from.
Make it less likely that further development will break compatibility with
ZULIP_ADMINISTRATORs of the form "name <email>".
Note that the suggested value for this setting has been
'zulip-admin@example.com' for a while, so hopefully this commit causes no
change for most installations.
This prevents users from accidentally sending a confirmation link
specific to their account to their Zulip administrator if they reply
to the invitation, invitation reminder, account confirmation, or new
email confirmation emails.
The file ioloop_logging.py is pretty small, but it seems to have
flaky time-sensitive code that creates noise for coverage deltas
when we do builds. Since it's small, we just exclude it.
Tweaked by tabbott to add comments.
We want a little bit of wiggle room for code coverage.
Some legitimate commits that remove code from the system
appear to reduce overall code coverage.
The `patch` option for code coverage only reports on lines that
are part of the patch, which tends to be misleading for things
like refactoring commits that may actually increase overall
code coverage for the project.
Eventually, we'll want to support unreacting to deactivated realm
emoji, but for now the issues around name conflicts mean we can't
really support that.
Instead of removing an emoji from the database, just mark them as
deactivated so that they can't be used further but can be rendered
properly in reactions and messages.
Fixes: #4750.
Deactivated emojis should not appear at any of the following places for
use:
1: Emoji pickers.
2: Composebox autocomplete.
3: Custom emoji settings page.
The backend errors are currently displayed to the right side of the
input field. This is different from the frontend validation errors
which are displayed at the bottom of the input field (and also looks
really bad). Also frontend validation uses <p> instead of <div> to
display errors so I have changed this also to make both uniform.
Tommy Ip
Brock Whittaker
Rishi Gupta
James Rowan
Steve Howell
Cory Lynch
Harshit Bansal
Jack Zhang
Cynthia Lin
Vishnu Ks
Vaida Plankyte
David Coleman