This commit fixes examples in "400" response for deactivating user
endpoints to have msg as "Cannot deactivate the last organization
owner" instead of "Cannot deactivate the last organization
administrator".
We had already removed the restriction on deactivating last admin
and added it for last owner, while adding owner role.
Improve OpenAPI documentation of /zulip-outgoing-webhook by moving
data and making appropriate additions from its couterpart in the
/outgoing-webhook docs. Then remove the redundant documentation
from the doc and add command to render OpenAPI documetation. Also
add a test to outgoing_webhooks_interface.py to ensure that OpenAPI
documentation is correct.
Fixes#16203.
This renames 'group_id' to 'user_group_id' in the api docs to remove
the naming mismatch between the url config and the docs and eventually
remove the 'user_groups' endpoints from 'pending_endpoints' in
test_openapi.py.
`update_message_flags` events used `operation` instead of `op`, the
latter being the standard field used in other events. So add `op`
field to `update_message_flags` and mark `operation` as deprecated,
so that it can be removed later.
For most cases you don't need to override `get_body`,
and for non-trivial cases, there's really no set pattern.
(It would be nice if we didn't default to json extensions
and just forced folks to be explicit about file extensions,
which would remove a whole class of `get_body` overrides.)
Not all webhook payloads are json, so send_json_payload was a
bit misleading.
In passing I also remove "bytes" from the Union type for
"payload" parameter.
Almost all webhook tests use this helper, except a few
webhooks that write to private streams.
Being concise is important here, and the name
`self.send_and_test_stream_message` always confused
me, since it sounds you're sending a stream message,
and it leaves out the webhook piece.
We should consider renaming `send_and_test_private_message`
to something like `check_webhook_private`, but I couldn't
decide on a great name, and it's very rarely used. So
for now I just made sure the docstrings of the two
sibling functions reference each other.
This commit adds "role" field to the Subscription objects passed to
clients. This is important preparation for being able to work on the
frontend for this feature.
This restores the Tab + Enter shortcut to send.
We are floating the send button to the right so that it still looks like
before. Instead of moving the button we could have also given every
message control button a tabindex, but these would be cumbersome to
maintain.
Tweaked by tabbott to add a comment recording the reasoning behind
the somewhat unusual CSS here.
Part of #15910.
Previously the emoji picker, the formatting help, the button to attach
files, the video call button, the Drafts button and the Press Enter to
send checkbox were all inaccessible from the keyboard.
This does break the Tab + Enter workflow for sending messages, which is
fixed in the next commit by moving the Send button to be the first
element after the textarea.
Part of #15910.
Apparently, we were incorrectly using constants for title/description
rather than the nice non-constant values from og:title and
og:description in our meta tags.
This adds 'user_id' to the simple success response for 'POST /users'
api endpoint, to make it convenient for API clients to get details
about users they just created. Appropriate changes have been made in
the docs and test_users.py.
Fixes#16072.
Prior to commit eb4a2b9d4e the center
area of the navbar was based on a structure that appended crumbs or
"tabs" as <li>s, forming a tab_bar and a tab_list.
However, in eb4a2b9d4e we apply a new
style and structure to the navbar which lets go of the convention of
tabs. Hence, we'd like to purge the tab_bar and tab_list labels from
our code base.
We purged tab_list in 1267caf5009118875f47fdafe312880af08024e1.
This commit purges tab_bar, it includes:
- A blanket search and replace of tab_bar with message_view_header.
- Splitting a single line comment in
tab_bar.js / message_view_header.js.
- The renaming of tab_bar.js to message_view_header.js.
- The renaming of tab_bar.hbs to message_view_header.hbs.
- A blanket search and replace of tab_data with
message_view_header_data.
- Replacing the single occurrence of tabbar with message_view_header
(it was within a comment.)
For all buttons in the compose box, `href="#"` is replaced
by "tabindex=0" so that the buttons are still focusable.
This change also fixes a bug that caused the Formatting
button to redirect to All messages.
Previously the title for all pages of the user and API documentation was
just "Zulip", which does not only bad for UX but also for accessibility.
We were already extracting the title from the Markdown for the og:title
tag, so we just need to set the <title> tag.
Since our documentation fetches pages with Ajax if you have JavaScript
enabled, we also need to save the titles in the article cache.
Part of #15948.
The apple developer webapp consistently refers this App ID. So,
this clears any confusion that can occur.
Since python social auth only requires us to include App ID in
_AUDIENCE(a list), we do that in computed settings making it easier for
server admin and we make it much clear by having it set to
APP_ID instead of BUNDLE_ID.
Improved markup of help-text.
Showing Email as plain-text instead of disabled input.
Changed page heading to 'Create your organization' in realm creation form
and 'Create your account' in normal signup form.
Grouped org settings and user settings with fieldsets.
Reduced space between Password field and Password strength bar.
Also, updated the corresponding test cases.
Partially Fixes: #15750.
Three reasons:
1. The sliding was disorienting.
2. The collapsing disallowed searching for other pages with Ctrl+F.
3. The collapsing mechanism wasn't accessible (not usable with the
keyboard / no ARIA tags).
Tweaked by tabbott to center the left sidebar on the selected page.
Part of #15948.
I'm not sure how this got added; it seems to have happened in a visual
redesign of the /features page. Certainly the claim should only have
been added after the work it described was done, and it has not.
The comments within update_message_backend function of views/message_edit.py
indicates 4 types of permissions which all edit a message. The 4th of these
indicates that a message is editable if the realm allows topic edits. This
was previously missing from the docs and is now added.