Commit Graph

17 Commits

Author SHA1 Message Date
Sam f21a4a6cb3
Revert "FIX: Allow category moderators to move topics to their categories" (#23810)
This reverts commit 70be873b9c.
2023-10-06 09:00:22 +08:00
Natalie Tay 70be873b9c
FIX: Allow category moderators to move topics to their categories (#20896) 2023-10-03 17:59:16 +08:00
Guhyoun Nam b70bd4366b
FEATURE: Separated 'trusted users can edit others' setting for trust level 3 & 4 (#21493) 2023-07-07 10:48:14 -05:00
锦心 96a2893284
FEATURE: Allow expanding hidden posts for groups in SiteSetting.can_see_hidden_post (#21853)
Allow expanding hidden posts for groups in SiteSetting.can_see_hidden_post
2023-06-01 11:32:05 +08:00
Ted Johansson 02625d1edd
DEV: Only allow expanding hidden posts for author and staff (#21052) 2023-04-25 13:37:29 +08:00
Ted Johansson b50b63808c
DEV: Make Guardian#can_see? default to false for unwatched objects (#20412)
When invoking e.g. `can_see?(Foo.new)`, the guardian checks if there's a method `#can_see_foo?` defined and if so uses that to determine whether the user can see it or not.

When such a method is not defined, the guardian currently returns `true`, but it is probably a better call (pun intended) to make it "safe by default" and return `false` instead. I.e. if you can't explicitly see it, you can't see it at all.

This change makes the change to `Guardian#can_see?` to fall back to `false` if no visibility check method is defined.

For `#can_see_user?` and `#can_see_tag?` we don't have any particular logic that prevents viewing. We previously relied on the implicit `true` value, but since that's now change to `false`, I have explicitly implemented these two methods in `UserGuardian` and `TagGuardian` modules. If in the future we want to add some logic for it, this would be the place.

To be clear, **the behaviour remains the same**, but the `true` value is now explicit rather than implicit.
2023-02-24 15:57:01 +08:00
Krzysztof Kotlarek 010370f8b1
FIX: error anonymous when tl4_delete_posts_and_topics setting (#20257)
Bug introduced in this PR: https://github.com/discourse/discourse/pull/19946

When the setting is enabled, an error is triggered for anonymous users.
2023-02-13 15:34:04 +11:00
Krzysztof Kotlarek ae20ce8654
FIX: TL4 user can see deleted topics (#19946)
New feature that TL4 users can delete/recover topics and post was introduced https://github.com/discourse/discourse/pull/19766

One guardian was missed to ensure that can see deleted topics
2023-01-23 12:02:47 +11:00
Ted Johansson 9cdeb93375
FEATURE: Allow TL4 users to see unlisted topics (#19890)
TL4 users can already list and unlist topics, but they can't see
the unlisted topics. This change brings this to par by allowing
TL4 users to also see unlisted topics.
2023-01-17 16:50:15 +08:00
David Taylor cb932d6ee1
DEV: Apply syntax_tree formatting to `spec/*` 2023-01-09 11:49:28 +00:00
Selase Krakani 0ce38bd7bc
SECURITY: Restrict unlisted topic creation (#19259) 2022-12-01 10:26:35 +00:00
Sam 4f63bc8ed2
FEATURE: hidden site setting to suppress unsecured categories from admins (#19098)
The hidden site setting `suppress_secured_categories_from_admin` will
suppress visibility of categories without explicit access from admins
in a few key areas (category drop downs and topic lists)

It is not intended to be a security wall since admins can amend any site
setting. Instead it is feature that allows hiding the categories from the
UI.

Admins will still be able to see topics in categories without explicit
access using direct URLs or flags.

Co-authored-by: Alan Guo Xiang Tan <gxtan1990@gmail.com>
2022-11-18 14:37:36 +11:00
Alan Guo Xiang Tan a473e352de
DEV: Introduce TopicGuardian#can_see_topic_ids method (#18692)
Before this commit, there was no way for us to efficiently check an
array of topics for which a user can see. Therefore, this commit
introduces the `TopicGuardian#can_see_topic_ids` method which accepts an
array of `Topic#id`s and filters out the ids which the user is not
allowed to see. The `TopicGuardian#can_see_topic_ids` method is meant to
maintain feature parity with `TopicGuardian#can_see_topic?` at all
times so a consistency check has been added in our tests to ensure that
`TopicGuardian#can_see_topic_ids` returns the same result as
`TopicGuardian#can_see_topic?`. In the near future, the plan is for us
to switch to `TopicGuardian#can_see_topic_ids` completely but I'm not
doing that in this commit as we have to be careful with the performance
impact of such a change.

This method is currently not being used in the current commit but will
be relied on in a subsequent commit.
2022-10-27 06:13:21 +08:00
Loïc Guitaut 3eaac56797 DEV: Use proper wording for contexts in specs 2022-08-04 11:05:02 +02:00
Phil Pirozhkov 493d437e79
Add RSpec 4 compatibility (#17652)
* Remove outdated option

04078317ba

* Use the non-globally exposed RSpec syntax

https://github.com/rspec/rspec-core/pull/2803

* Use the non-globally exposed RSpec syntax, cont

https://github.com/rspec/rspec-core/pull/2803

* Comply to strict predicate matchers

See:
 - https://github.com/rspec/rspec-expectations/pull/1195
 - https://github.com/rspec/rspec-expectations/pull/1196
 - https://github.com/rspec/rspec-expectations/pull/1277
2022-07-28 10:27:38 +08:00
David Taylor c9dab6fd08
DEV: Automatically require 'rails_helper' in all specs (#16077)
It's very easy to forget to add `require 'rails_helper'` at the top of every core/plugin spec file, and omissions can cause some very confusing/sporadic errors.

By setting this flag in `.rspec`, we can remove the need for `require 'rails_helper'` entirely.
2022-03-01 17:50:50 +00:00
Jarek Radosz 45cc16098d
DEV: Move spec/components to spec/lib (#15987)
Lib specs were inexplicably split into two directories (`lib` and `components`)

This moves them all into `lib`.
2022-02-18 19:41:54 +01:00