can_permanently_delete field in Post and TopicViewDetails serializers
cannot use Guardian's can_permanently_delete beause their use is
different. The field from the serializers is used to show the button
and the button is shown even if the post cannot be removed forever
because not enough time has passed since it was first deleted. The
guardian method is used by the controller to check that the post can
really be deleted.
Previous to this change if any of the assets were not allowed extensions
they would simply be silently ignored, this could lead to broken themes
that are very hard to debug
Our group fabrication creates groups with name "my_group_#{n}" where n
is the sequence number of the group being created. However, this can
cause the test to be flaky if and when a group with name `my_group_10`
is created as it will be ordered before
`my_group_9`. This commits makes the group names determinstic to
eliminate any flakiness.
This reverts commit 558bc6b746.
The links returned by post.url and topic.url are relative, but contain
the subdirectory. When getAbsoluteURL is called to construct the
complete share URL, it adds the host and the subdirectory again. As a
result the created URLs contained the subdirectory twice.
The user avatar in posts has aria-hidden set to true to reduce
redundancy since the information that the avatar gives to screen readers
is the same information that the username/name of the post gives which
is the author of the post.
However, it's still possible for a screen reader user to reach the
avatar by tabbing through the post and when that happens the avatar is
read as "blank". This isn't ideal so we should set tabindex to -1 on the
avatar to remove it from the default keyboard nav flow.
The changes are:
* Add an aria-label for the button that embeds/expand the replies of a
post below it
* Add an aria-label for the button that collapses the embedded replies
* Add an aria-label to describe the embedded replies section when
expanded and an aria-label for each embedded reply
The improvements are:
* Add an aria-label to the like/read count buttons below posts to
indicate what they mean and do.
* Add aria-pressed to the like/read count buttons to make it clear to screen
readers that these buttons are toggleable.
* Add an aria-label to the list of avatars that's shown when post likes
or readers are expanded so that screen reader users can understand what
the list of avatars means.
The tabLoc is a hidden element inside the post region that we use to
move the focus close to the post that's visually highlighted (by
changing the background color and then fading it away) when a topic is
opened so that screen readers can start reading from that post rather
than the top of the page.
Some screen readers get confused by the tabLoc element being an `<a>`
element and read out the topic ID and I've found that changing the tag
to `<span>` fixes the problem.
We want our autoloading to respect custom inflections registered with ActiveSupport::Inflector. `Zeitwek::Inflector` does not call out to ActiveSupport.
Instead, we can define our own DiscourseInflector based on the super-simple Inflector in rails core.
Follow-up to 5743a6ec
In certain instances when viewing a category, the name of a group with
restricted visilbity may be revealed to users which do not have the
required permission.
More precisely, if popper can't position something at the bottom, it will automatically attempt to position it at the top. However we should ensure it doesn’t consider the space under the d-header as valid space, when header's height is taken into consideration if top space is not enough, we should force bottom, and flip it back.
This logic is not necessary on modals as the d-header is not present.
This commit introduces a new use_polymorphic_bookmarks site setting
that is default false and hidden, that will be used to help continuous
development of polymorphic bookmarks. This setting **should not** be
enabled anywhere in production yet, it is purely for local development.
This commit uses the setting to enable create/update/delete actions
for polymorphic bookmarks on the server and client side. The bookmark
interactions on topics/posts are all usable. Listing, searching,
sending bookmark reminders, and other edge cases will be handled
in subsequent PRs.
Comprehensive UI tests will be added in the final PR -- we already
have them for regular bookmarks, so it will just be a matter of
changing them to be for polymorphic bookmarks.
`keyUp` is only invoked if the component's root element (or one of its descendants) has focus which isn't great for keyboard users because if they open a user card and want to close it, they have to tab through to the user card and only then will the Esc key actually close the card. This commit adds a `keyup` event listener on the `document` for the Esc key so that the user card is closed (if it's open) no matter where the focus is.
Under some conditions, replacing an `<img` with `![]()` can break rendering, and make the image disappear.
Context at https://meta.discourse.org/t/152801
Since 3fd7b31a2a some tests
were failing with this error:
> Error: Unhandled request in test environment: /c/feature/find_by_slug.json
> (GET) at http://localhost:7357/assets/test-helpers.js
This commit fixes the issue by adding the missing pretender. Also
noticed while fixing this that the parameter for the translation
was incorrect -- it was `group` instead of `groupNames`, so that
is fixed here too, along with moving the onShow functions into
@afterRender decorated private functions. There is no need for the
appevent listeners.
* DEV: add testing for multi del on keys
Following #15905 we were missing some tests, this covers cases where
del is used in the form of .del(key1,key2)
Tags (and tag groups) can be configured so that they can only be used in specific categories and (optionally) restrict topics in these categories to be able to add/use only these tags. These restrictions work as expected when a topic is created without going through the review queue; however, if the topic has to be reviewed by a moderator then these restrictions currently aren't checked before the topic is sent to the review queue, but they're checked later when a moderator tries to approve the topic. This is because if a user manages to submit a topic that doesn't meet the restrictions, moderators won't be able to approve and it'll be stuck in the review queue.
This PR prevents topics that don't meet the tags requirements from being sent to the review queue and shows the poster an error message that indicates which tags that cannot be used.
Internal ticket: t60562.
