`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.
Alex Vandiver
Prakhar Pratyush
Alya Abbott
Aman Agrawal
Lauryn Menard
Lauryn Menard
Sahil Batra
Anders Kaseorg
David Rosa
Brijmohan Siyag
Alya Abbott
Lauryn Menard
Tim Abbott
Duncan