Commit Graph

11 Commits

Author SHA1 Message Date
Krzysztof Kotlarek
20982ef875
FIX: change Community icons (#21904)
Because of typo, icon could not be changed.
2023-06-02 11:58:54 +10:00
Krzysztof Kotlarek
9f78ff5572
FEATURE: modal for admins to edit Community section (#21668)
Allow admins to edit Community section. This includes drag and drop reorder, change names, delete and reset to default.

Visual improvements introduced in edit community section modal are available in edit custom section form as well. For example:
- drag and drop links to change their position;
- smaller icon picker.
2023-05-29 15:20:23 +10:00
Alan Guo Xiang Tan
b183b997fb
UX: Add custom section button should not be shown to anon users (#21651) 2023-05-19 09:31:25 +08:00
Alan Guo Xiang Tan
e323628d8a
DEV: Speed up core system tests (#21394)
What is the problem?

We are relying on RSpec custom matchers in system tests by defining
predicates in page objects. The problem is that this can result in a
system test unnecessarily waiting up till the full duration of
Capybara's default wait time when the RSpec custom matcher is used with
`not_to`. Considering this topic page object where we have a `has_post?`
predicate defined.

```
class Topic < PageObject
  def has_post?
    has_css?('something')
  end
end
```

The assertion `expect(Topic.new).not_to have_post` will end up waiting
the full Capybara's default wait time since the RSpec custom matcher is
calling Capybara's `has_css?` method which will wait until the selector
appear. If the selector has already disappeared by the time the
assertion is called, we end up waiting for something that will never
exists.

This commit fixes such cases by introducing new predicates that uses
the `has_no_*` versions of Capybara's node matchers.

For future reference, `to have_css` and `not_to have_css` is safe to sue
because the RSpec matcher defined by Capbyara is smart enough to call
`has_css?` or `has_no_css?` based on the expectation of the assertion.
2023-05-05 07:45:53 +08:00
Alan Guo Xiang Tan
2eb60c9713
DEV: Switch sidebar section link identifier to data attribute (#21051)
Data attribute is less restrictive than relying on the class attribute
2023-04-12 15:52:10 +08:00
Krzysztof Kotlarek
e586f6052f
FEATURE: public custom sidebar sections visible to anonymous (#20931)
Previously, public custom sections were only visible to logged-in users. In this PR, we are making them visible to anonymous as well.

The reason is that Community Section will be moved into custom section model to be easily editable by admins.
2023-04-06 08:55:47 +10:00
Alan Guo Xiang Tan
2d46824a87
DEV: Switch to data attributes to represent sidebar section name (#20771)
Data attributes are less restrictive than the class attribute.
2023-03-23 13:09:45 +08:00
Krzysztof Kotlarek
a16ea24461
FEATURE: allow external links in custom sidebar sections (#20503)
Originally, only Discourse site links were available. After feedback, it was decided to extend this feature to external URLs.

/t/93491
2023-03-07 11:47:18 +11:00
Alan Guo Xiang Tan
d71a82786a
UX: Hide hamburger dropdown when enable_sidebar query param is used (#20367) 2023-02-20 11:34:37 +08:00
Krzysztof Kotlarek
84a87a703c
DEV: configurable custom sidebar sections (#20057)
Allows users to configure their own custom sidebar sections with links withing Discourse instance. Links can be passed as relative path, for example "/tags" or full URL.

Only path is saved in DB, so when Discourse domain is changed, links will be still valid.

Feature is hidden behind SiteSetting.enable_custom_sidebar_sections. This hidden setting determines the group which members have access to this new feature.
2023-02-03 14:44:40 +11:00
Alan Guo Xiang Tan
5db72f8daf
FIX: Preload user sidebar attrs when ?enable_sidebar=1 (#19843)
This allows users to preview the sidebar even when
`SiteSetting.naviation_menu` is set to `false`.
2023-01-13 06:47:58 +08:00