The string "Or import from Slack, Mattermost, Gitter, or
Rocket.Chat." in create_realm.html was not tagged for
translation before. This commit fixes it to tag the string
for translation.
`render_markdown_path` renders Markdown, and also (since baff121115)
runs Jinja2 on the resulting HTML.
The `pure_markdown` flag was added in 0a99fa2fd6, and did two
things: retried the path directly in the filesystem if it wasn't found
by the Jinja2 resolver, and also skipped the subsequent Jinja2
templating step (regardless of where the content was found). In this
context, the name `pure_markdown` made some sense. The only two
callsites were the TOS and privacy policy renders, which might have
had user-supplied arbitrary paths, and we wished to handle absolute
paths in addition to ones inside `templates/`.
Unfortunately, the follow-up of 01bd55bbcb did not refactor the
logic -- it changed it, by making `pure_markdown` only do the former
of the two behaviors. Passing `pure_markdown=True` after that commit
still caused it to always run Jinja2, but allowed it to look elsewhere
in the filesystem.
This set the stage for calls, such as the one introduced in
dedea23745, which passed both a context for Jinja2, as well as
`pure_markdown=True` implying that Jinja2 was not to be used.
Split the two previous behaviors of the `pure_markdown` flag, and use
pre-existing data to control them, rather than an explicit flag. For
handling policy information which is stored at an absolute path
outside of the template root, we switch to using the template search
path if and only if the path is relative. This also closes the
potential inconsistency based on CWD when `pure_markdown=True` was
passed and the path was relative, not absolute.
Decide whether to run Jinja2 based on if a context is passed in at
all. This restores the behavior in the initial 0a99fa2fd6 where a
call to `rendar_markdown_path` could be made to just render markdown,
and not some other unmentioned and unrelated templating language as
well.
Currently, there is a checkbox setting for whether to
"Include realm name in subject of message notification emails".
This commit replaces the checkbox setting with a dropdown
having values: Automatic [default], Always, Never.
The Automatic option includes the realm name if, and only if,
there are multiple Zulip realms associated with the user's email.
Tests are added and(or) modified.
Fixes: #19905.
Adds a section in the development community norms about using the
custom linkifiers in chat.zulip for the different Zulip project
repositories on GitHub.
While the function which processes the realm registration and
signup remains the same, we use different urls and functions to
call the process so that we can separately track them. This will
help us know the conversion rate of realm registration after
receiving the confirmation link.
Creates new help article for supported web browsers. Also updates
links in the `/apps` landing page as well as the unsupported-browser
template and the `set-up-your-account` article.
Fixes#14732.
Updates the Asana documentation, which was a detailed version
of the Zapier documentation with screenshots specifically for
Asana, to instead start with the basic incoming webhook steps
and then point to the general Zapier documentation to complete
the integration.
This will be easier to maintain moving forward in the short
term as ideally we'll migrate to a system that documents all
of the integrations with Zulip that are available via Zapier.
Also, updates the current Zapier documentation to mention
Asana as one of the apps that can be integrated with Zulip.
Updates the text and title used when the password reset done page
to work for situations where the user is resetting a forgotten
password and for situation where the user is setting a password
for the first time (e.g. SSO login, demo organizations).
We now allow user to change email_address_visibility during user
signup and it overrides the realm-level default and also overrides
the setting if user import settings from existing account.
We do not show UI to set email_address_visibility during realm
creation.
Fixes#24310.
- Updates `.prettierignore` for the new directory.
- Updates any reference to the API documentation directory for
markdown files to be `api_docs/` instead of `zerver/api/`.
- Removes a reference link from `docs/documentation/api.md` that
hasn't referenced anything in the text since commit 0542c60.
- Update rendering of API documentation for new directory.
- Clean up the language.
- Add a prominent "Go to organization" button.
- Link to guides for new users and admins.
- Fix duplication bug in text email version.
Co-authored-by: Mateusz Mandera <mateusz.mandera@zulip.com>
This commit adds "bootstrap-focus-style" class to the select
elements such that we can add CSS rule for focusing a select
element at single place only using this class.
This commit adds bootstrap CSS rules used for org type select
element in sponsorship page in billing.css.
This change is done so we can safely remove select CSS rules
from bootstrap.css as a part of our process to remove bootstrap.
We also remove inline style for this element and instead add
it with other CSS in billing.css.
This commit refactors the template code for source-realm
select element to have same structure as other inputs
and select element in the page. Thus this change also
makes the styling of source-realm select element consistent
with other select element in the page.
We do not need "required" attribute in the org-type select element
in sponsorship form, since we select a value by default and there
is no way to not have any value for the select element.
Also, the "required" attribute was added twice somehow.
These files are not Jinja2 templates, so there's no reason that they needed
to be inside `templates/zerver`. Moving them to the top level reflects their
importance and also makes it feel nicer to work on editing the help center content,
without it being unnecessary buried deep in the codebase.
This commit removes form-horizontal class from password reset
pages (page in which user enters the email and the page where
user sets the new password) and user register page.
We can safely remove the form-horizontal class, since the
vertical-align property is already applied by other CSS
in bootstrap and margin is overridden by CSS in
portico_signin.css.
For checkbox type inputs, the display property is already set
to inline-block by browser for all input elements but it is
eventually computed to "block" since float property for this
element is set to left. So, setting display property is not
necessary for checkbox input.
For the help-inline elements, the display and margin properties
are overridden in portico_signin.css and vertical-align property
is handled by CSS for "help-inline" class in bootstrap.css.
This commit removes form-horizontal class from form elements
in social_auth_select_email.html. There is no visible input
element in the form element so the bootstrap CSS using
"form-horizontal" class does not apply to any of the elments
in the page, so removing this class does not have any affect.
The "form-horizontal" class is used in portico-signin.css for
adding hover behavior, so we add a new class "select-email-form"
and use it to add the hover behavior.
This commit removes form-horizontal class from account_accept_terms
template. We can safely remove this class because vertical-align
property is already handled for input element by other bootstrap CSS
and margin is overridden by CSS in portico.css. The display property
is already set to inline-block by browser for all input elements
but it is eventually computed to "block" since float property for
this element is set to left.
For the "p" element used to display errors, the display and margin
properties are overridden in portico_signin.css and vertical-align
property is handled by CSS for "help-inline" class in bootstrap.css.
We can safely remove the form-horizontal class from form element in
support request page, since the display and vertical-align are already
applied by other CSS in bootstrap and margin is overridden by CSS in
portico_signin.css.
Documents link to the bot's user card from the bot's name in
Organization settings > Bots, and information in the bot's user card.
Fixes part of #23970.
Updates the help center article to match the style and formatting
of "Import from Slack" and replaces existing content with its
corresponding Markdown macro.
Updates the help center article to match the style and formatting
of "Import from Slack" and replaces existing content with its
corresponding Markdown macro.
The message recipient bar instructions are now contained in a tip
block, as suggested in #22178.
Refines wording for unmuting topics on desktop/web.
This will allow adding mobile instructions to the article.
Overrides the default context `allow_search_engine_indexing` to
always be `False` for `templates/corporate/attribution.html` so
that it does not appear in Google / search engine indexes.
Updates test of documentation pages in `test_docs.py` to have an
option for corporate pages to set this value in the template and
verifies that the meta tag for robots noindex, nofollow is
always in the response.
Removes the `btn-direct` class in `portico.css` that was only
being used for dev login buttons.
Adds `dev-button` class for general CSS rules for buttons on the
dev login page. Adds `dev-login-button` and `dev-create-button`
classes for CSS rules specific to the two types of buttons on the
page.
Adds links to the documentation about management commands in the
API documentation for creating users, as well as the `/devtools`
documentation, the GDPR compliance article and the incoming
webhooks tutorial.
Previously, `templates/zerver/api/missing.md` was a symlink to the
file in the help center documentation.
Prep commit for moving the help center documentation to a top level
directory.
Updates the help center articles on restricting email and avatar
changes so that it is clear that administrators can always change
these settings for themselves.
Also, fixes a broken link and a few small text/formatting errors.
--attachments is redundant and should not be used:
```
$ mmctl export create --attachments
Flag --attachments has been deprecated, the tool now includes attachments by default. The flag will be removed in a future version.
```
Prep commit for creating demo organizations in the development
environment with a blank email address for organization owners.
Changes the input element for organization owners into a button
element, so that text other than the input value can be displayed.
Renames and cleans up some of the CSS rules for the `btn-admin`
class that is used in the dev login page for input elements.
Confirmed via git-grep that this class is only used on the dev
login page.
Updates the help center article to match the style and formatting
of "Import from Slack" and replaces existing content with its
corresponding Markdown macro.
The figure element here was used for a text bubble rather than a
graphics (i.e. "figure"), hence a div element is more appropriate.
This change doesn't effect the visual styling as verfied by comparing
the rendered result visually, and comparing the applied styles in the
devtools.
Some email clients (notably, Gmail Web) support automatically threading
emails together if recipients and subjects match[1]. Manual testing
indicated that prefixing a subject with "[bracketed content]" does not
break this threading behavior, but the added checkmark in a resolved
topic's title does. Before sending an email notification, determine
whether the topic is resolved, and pass this information to the Jinja
template to properly format a threadable email subject.
Fixes: #22538
[1]: https://support.google.com/mail/answer/5900
Previously, stream names and topics (without consideration for their
resolution status) were concatenated in Python-land and passed through
to the template. To more cleanly separate concerns, and to prepare for
accounting for topic resolution status being a third, independent,
component of a subject line, instead pass stream and topic strings
independently to the Jinja template, which can format them as it sees
fit.
This commit changes the topic edit permssions to not depend whether the user
editing the message had sent the message or it was sent by someone else.
We only do backend changes in this commit and frontend changes will be done
in further commits.
Previously, we always allowed topic edits when the user themseleves had
sent the message not considering the edit_topic_policy and the 3-day time
limit. But now we consider all messages as same and editing is allowed only
according to edit_topic_policy setting and the time limit of 3 days in
addition for users who are not admins or moderators.
We change the topic and stream edit permssions to not depend on
allow_message_editing setting in the API and are allowed even
if allow_message_editing is set to False based on other settings
like edit_topic_policy and can_move_message_between_streams.
Fixes a part of #21739.
Alya Abbott
Alex Vandiver
Aman Agrawal
Sahil Batra
Prakhar Pratyush
Lauryn Menard
Lauryn Menard
Anders Kaseorg
David Rosa
Brijmohan Siyag
Alya Abbott
Lauryn Menard
Tim Abbott
Duncan
Mateusz Mandera
Sebastian Noack
Josh Klar