Updates the base titles so that they begin with the page content,
and end with "| Zulip" + information about the type of doc: "help
center", "API documentation", "terms and policies", or "integrations".
Adds a META_CATEGORY dict for categories that are not best described
as groups of 'tools', so that in the subsequent commit the PAGE_TITLE
can be set accordingly.
Also, removes 'tools' from the 'Miscellaneous' category text and
spells out 'Human resources' instead of using 'HR'.
Since we are updating the help center documentation to use `<kbd>`
HTML elements when documenting keyboard keys and shortcuts, we no
longer need to support `<code>` HTML elements in
`adjust_mac_shortcuts`.
Updates the tutorial in "Writing help center articles: Writing
style" for using `<kbd>` HTML elements when documenting keyboard
shortcuts in help center articles.
Also, adds section about the keyboard tip macro/syntax.
Updates references to keyboard keys in the help center docs to use
`<kbd>` HTML elements, which also means updating them to be as the
key would appear on a keyboard.
Previously, uppercase and lowercase letters were used to indicate
when/if the `Shift` key was being used, and even that was not
consistent throughout the documentation.
For CSS styling, adds a similar rule for `<kbd>` elements that is
used in `/static/styles/app_components.css`. And updates the CSS
class used in `/static/js/portico/help.js` for `adjust_mac_shortcuts`
accordingly.
Also, takes advantage of revising these pages for making small
updates for current help center documentation practices.
We do not need direct_members and direct_subgroups field of
UserGroup objects in the export data since we already have
UserGroupMembership and GroupGroupMembership object data.
While importing we keep these fields empty when creating
UserGroup objects and direct_members and direct_subgroups
fields will get set when UserGroupMembership and
GroupGroupMembership objects are created.
This change will also help us in further changes when we
will change the order of importing to import UserGroup
objects just after Realm objects.
Although our POST /messages handler accepts the ‘to’ parameter with or
without JSON encoding, there are two problems with passing it as an
unencoded string.
Firstly, you’d fail to send a message to a stream named ‘true’ or
‘false’ or ‘null’ or ‘2022’, as the JSON interpretation is prioritized
over the plain string interpretation.
Secondly, and more importantly for our tests, it violates our OpenAPI
schema, which requires the parameter to be JSON-encoded. This is
because OpenAPI has no concept of a parameter that’s “optionally
JSON-encoded”, nor should it: such a parameter cannot be unambiguously
decoded for the reason above.
Our version of openapi-core doesn’t currently detect this schema
violation, but after the next upgrade it will.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The previous schema incorrectly prohibited the string, integer, and
string-array forms that we do in fact accept.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
The previous schema incorrectly prohibited the two-element array form
that we do in fact accept, and didn’t specify anything about the
contents of the object form.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Adds a legend to the "org-registration" fieldset where the user
inputs info about the new organization. Previously, there was only
a legend for the "user-registration" fieldset. Also, increases
the opacity of CSS rule for the legend color so that they are
more visible.
Removes the hint text about what the organization URL value is
used for since it is pretty clear from the field's name.
Disable "External account type" select field from External account type
profile field edit form, doing it because this select field is not
editable and it is incorrectly looks like editable.
change the names of "github" and "twitter" external account fields to
"GitHub username" and "Twitter username" respectively and remove the
hints of them.
Removes the prefilled support email content in `500.html` and
`unsubscribe_link_error.html` templates since both cases are rather
rare and the prefilled content is not useful for organizations that
do not use English as their main communication language.
In 5c49e4ba06, we neglected to include
the CSRF and caching decorators required for all API views in the new
remote_server_dispatch function.
I'm not sure why our automated tests didn't catch this, but this made
the remote server API endpoints nonfunctional in a production
environment.
Until now, whenever typeahead autocompleted the spoiler syntax, there
was no indication if and how a visible header to the hidden content
could be added.
Now when autocompleting, the word "Header" is added as a placeholder
and highlighted, hinting at the format.
Fixes: #20868.
This makes the implementation more readable, and also dependant only
on the `highlight` object, not the detail that previously only slash
commands, which have an `item.placeholder`, used this code path.
This may have originally made sense as a class that managed the
browser state, but it has since turned into a dumping ground for
mostly pure functions that don’t make sense to instantiate.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This is part of redesigning messages (#22059). This commit adds
classnames to messages with mentions, differentiating direct mentions
from wildcard mentions from usergroup mentions, and this set us up
for a future commit where we'll have those different kinds of messages
be displayed in different colors.
If there are more than 1 room with the same set of users, the import
will fail due to a unique constraint on the huddle_hash. Figuring out
why and which room is causing this database error is kinda difficult.
We deduplicate those cases here and simply merge the rooms together.
Note however, that the deduplication does not work as expected so we
simply ignore them all together for now and only raise an exception
along some logging output. At least this way, it is pretty clear what is
wrong and you do not have to wait to get a database error during the
actual import.
We also ignore empty huddle rooms since those are the duplicates that
caused problems for me and if they are empty, ignoring them is easier
than trying to get the merge to work.
Not sure where those channels come from since we discovered this with
production data.
Signed-off-by: Florian Pritz <bluewind@xinu.at>
Not sure where those come from since we discovered this with production
data. Somehow there were reactions with usernames that were old and no
longer existed.
Signed-off-by: Florian Pritz <bluewind@xinu.at>
Not sure where those come from since we discovered this with production
data.
There only was a single instance of this in my entire batch of data in
an old message from the time when we started using Rocket.Chat. This
might be an old issue or it might require some special settings that
were later changed.
Signed-off-by: Florian Pritz <bluewind@xinu.at>
There are a handful of integration docs that instruct users to create
a bot and select the "Generic bot" type without using a helper macro.
Adds a new macro to replace these instructions, including a screenshot
of the latest UI for selecting a bot type.
Several integration docs instruct the user to create a bot, but don't
specify that the type of bot should be "Incoming webhook".
Renames create-a-bot.md -> create-an-incoming-webhook.md for clarity,
and replaces all incomplete instructions with this macro.
Renames bot_types.png -> bot_types_incoming_webhook.png and updates
the image with a screenshot of the latest UI.