* pagination theme for new admin view
* align pagination widget correctly in desktop view
* remove bottom pagination
* re-add pagination to the bottom
* use block styling for the links
We already have a partial unique index for this column scoped on
`published = true`, which is still useful. This index does not make that
index redundant because that index is used to enforce a constraint that
we *only* want to apply to published articles. This index will be used
when `WHERE published` is not part of the query.
* Add a comment, and a safe default value for cloudinary
When moving a site from imgproxy to cloudinary, we observed that
wrapping the cloud name in quotes caused off-looking urls (with the
user name in %22 escaped quotes).
Additionally, if cloudinary is enabled, cloudinary secure should
be set to true. We leave the others blank to prevent conditionally enabling this
service (we check for ENV var presence) mistakenly, but the secure
flag won't turn it on or off and is safe to keep a default value.
* remove unnecessary comment
quoting the env vars had no effect when tested.
As part of my AuthN/AuthZ work I'm reviewing policies. I've been
looking at Dashboard pseudo-policies. The dashboard has some implicit
organization policies that I'm looking to expose and describe.
This refactor simply leverages methods already on the user.
Discovered while working on forem/forem#16985
We only have one reference to the UnauthorizedError, which is shadows
the ApplicationPolicy::NotAuthorizedError. This commit removes the
exception.
Related to forem/forem#16985 but only barely
* Removing a JS message about connect
Related to forem/forem#14734
* Remvoing another reference
I ran `rg Connect[^i]` to see about any remaining references to
Connect. This one seems to be the last.
* Adjusting article copy to be more general
Our language regarding articles needs minor revisions to speak a bit
more generally about content. This follows on the features of
AuthN/AuthZ work to allow forem admins to configure their forems such
that a subset of their forem members may not have the ability to create
articles.
Closesforem/forem#16890Closesforem/forem#16891
* Update app/views/users/_notifications.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
As I'm looking at the dashboard, there's lots of small duplication.
This refactor is a way to help me collect my thoughts regarding how to
approach the larger issue at hand.
This menu item will show up once you have added the
`:limit_post_creation_to_admins` feature flag (regardless of whether
it is enabled or not).
If you wish to add the menu item:
```console
rails console runner "FeatureFlag.add(:limit_post_creation_to_admins)"
```
In "adding" the item, it will default to disabled. However, as an
administrator you should now be able to toggle on and off the
authorization enforcement.
If you wish to remove the menu item:
```console
rails console runner "FeatureFlag.remove(:limit_post_creation_to_admins)"
```
Future plans for this will be to remove the `FeatureFlag.exist?`
conditional so that the menu item shows up. A major consideration is
that we'll assume that all Forem's have a "default space" in which
folks (by default) can post.
Builds on forem/forem#16897Closesforem/forem#16842
* Adding ArticlePolicy#has_existing_articles_or_can_create_new_ones?
As part of our aspirations to only show users what is relevant to them
and "hiding" what is not, this method will help us with the edge case of
"should we show the user a dashboard listing of posts?"
Related to forem/forem#16837
* Adding further documentation
* Adding clarifying comment
This method was making a DB query every time. Chances are that if the
table is there the first time, it'll continue to exist. This is an
assumption generally baked into ActiveRecord - it caches the schema for
every table when its corresponding model is used and never checks it
again for the life of the process.
There is no reason to create an instance variable as we don't pass this
to the view. Further, by adding this as a before_action there's a
disconnect in logic.
This commit attempts to address those issues.
What follows is a three-fold change:
1. Removing the before action (let's just call the method)
2. Reworking the method to reduce, just a bit, the method cost
3. Removing an unused instance variable
Here are the benchmarks. Note the "follows_limit" as written below is
the "Proposed" route.
```ruby
require 'benchmark'
def follows_limit_original(params:, default: 80, max: 1000)
per_page = (params[:per_page] || default).to_i
@follows_limit = [per_page, max].min
end
def follows_limit(params:, default: 80, max: 1000)
return default unless params.key?(:per_page)
per_page = params[:per_page].to_i
return max
per_page
end
def follows_limit_alt(params:, default: 80, max: 1000)
per_page = params.fetch(:per_page, default).to_i
return max if per_page > max
per_page
end
TIMES = 10_000
Benchmark.bmbm do |b|
b.report("Original no params") { 1000.times { follows_limit_original(params: {}) } }
b.report("Original less than max") { 1000.times { follows_limit_original(params: {per_page: 90 }) } }
b.report("Original greater than max") { 1000.times { follows_limit_original(params: {per_page: 9000 }) } }
b.report("Proposed no params") { 1000.times { follows_limit(params: {}) } }
b.report("Proposed less than max") { 1000.times { follows_limit(params: {per_page: 90 }) } }
b.report("Proposed greater than max") { 1000.times { follows_limit(params: {per_page: 9000 }) } }
b.report("Alt no params") { 1000.times { follows_limit_alt(params: {}) } }
b.report("Alt less than max") { 1000.times { follows_limit_alt(params: {per_page: 90 }) } }
b.report("Alt greater than max") { 1000.times { follows_limit_alt(params: {per_page: 9000 }) } }
end
```
```shell
$ ruby /Users/jfriesen/git/forem/bench.rb
Rehearsal -------------------------------------------------------------
Original no params 0.000403 0.000002 0.000405 ( 0.000405)
Original less than max 0.000109 0.000005 0.000114 ( 0.000114)
Original greater than max 0.000161 0.000006 0.000167 ( 0.000166)
Proposed no params 0.000076 0.000001 0.000077 ( 0.000076)
Proposed less than max 0.000114 0.000009 0.000123 ( 0.000126)
Proposed greater than max 0.000112 0.000011 0.000123 ( 0.000123)
Alt no params 0.000104 0.000007 0.000111 ( 0.000114)
Alt less than max 0.000113 0.000009 0.000122 ( 0.000122)
Alt greater than max 0.000111 0.000001 0.000112 ( 0.000115)
---------------------------------------------------- total: 0.001354sec
user system total real
Original no params 0.000108 0.000000 0.000108 ( 0.000110)
Original less than max 0.000109 0.000001 0.000110 ( 0.000111)
Original greater than max 0.000109 0.000000 0.000109 ( 0.000109)
Proposed no params 0.000071 0.000000 0.000071 ( 0.000071)
Proposed less than max 0.000103 0.000001 0.000104 ( 0.000103)
Proposed greater than max 0.000102 0.000000 0.000102 ( 0.000103)
Alt no params 0.000093 0.000000 0.000093 ( 0.000093)
Alt less than max 0.000103 0.000000 0.000103 ( 0.000104)
Alt greater than max 0.000102 0.000000 0.000102 ( 0.000103)
```
* Always show the browse section regardless of featured
* Add tests for /pod
* Use safe operator if there are no episodes to show
* Fix test for new podcast page
* Fix test again for podcast page
* symlink .env_sample as .env.test
* Remove unneeded copy from test setup
Now that there's always a valid environment (.env.test) present, we
don't need the .env file for test setup.
follow on to #15942 which enabled downloading existing DEV feeds, this
allows setting a feed url to DEV.
It's possible this user agent should be brought inline with the
tags choice of community name and url, but in the short term I'm
making this consistent with the existing feed importer.
There is an incredible amount of conditionals in play within this
controller. I'm working to disentangle the logic so we can introduce
unified authorization policies.
The first step is removing the quasi-opaque "before_action" behavior
related to authorization. My strong preference is to make that explicit
and in doing so begin to see how to adjust the policy enforcement/creation.
This relates to forem/forem#16913
While exploring the DashboardsController, I came across method calls to
`not_found`. Idiomatically, I assumed that these methods were returning
a value. However, in looking at the code, it raises an exception.
_Note: I excpect methods that raise exceptions, especially as the only
thing they do, to end in a `!`._
By adding the documentation my "IntelliSense" provides insight into the
expected behavior of this function (e.g. "Raises an exception").
Without the documentation, I don't see any useful information.
* prefer case to multiple if branches
case klass works fine on inheritance chains (we don't need to match on
inheritance explicitly).
* Verify case on error class behaves as before
* Fix tests
I don't know how I committed tests that were failing, but don't do that
As I was looking to implement the new Spaces feature (see
forem/forem#16842), I began looking at how to adjust the admin menu. I
found the Menu and AdminMenu. I wanted to add the "spaces" item under
the `:content_manager` scope. Looking at the implementation, I saw I
would need some additional branching logic.
To get an understanding of the implementation, I chose factor towards
classes.
This refactor does a few things:
1) Clarifies a method name (e.g. "children?" becomes
"has_multiple_children?")
2) Adds some tests of the menu implementation.
3) Removes deeply nested hashs in favor of first class objects.
4) Removes a complex method for determining menu visibility, instead
favoring a method that either takes a boolean OR a lambda.
There are further refactors to consider, especially in regards to the
helper methods and some of the coercion of strings into different
formats. But this refactor gets me the part I most am interested in:
Making it easier to specify a menu item as visible or not.
* Penciling in a Default Spaces section
This delivers two primary things:
1. Extracting shared policy examples
2. Providing a functioning skeleton for toggling on the
"limit_post_creation_to_admins" feature.
Important is that once merged, it would be possible for this code to
"leak" out. But how that leaks out is also how you can test that the
feature works.
First, to orient, there is a constraint for a new route. That
constraint checks if the feature flag exists (e.g. has been explicitly
enabled or explicitly disabled). In other words, at this point, you
can't accidentally enable the feature via the UI. But once you have
enabled the feature, you can then toggle the feature on and off.
So, to test this in the browser:
1. Pull down this branch
2. Run `rails runner "FeatureFlag.disable(:limit_post_creation_to_admins)"`
3. Startup your the web server.
4. Login as an administrator
5. Goto /admin/content_manager/spaces
a. Bask in the glory of a plain HTML form
6. With another browser, login as another non-admin user
7. Go to /settings/extensions, you should see a section Publishing from RSS.
8. Now with the admin's session, update the form to turn on
"limit_post_creation_to_admins"
9. Back to the non-admin browser, refresh /settings/extensions, you
should no longer see the section Publishing from RSS.
Note: I have not included an admin menu item as that is related to and
dependent on some refactors I'm working on (see forem/forem#16888 and
forem/forem#16847). So a bit of "security through obsurity"
Note: In the future, once we resolveforem/forem#16490, we'll start
toggling the "Create a Post" button.
Note: I am not including Cypress tests nor request tests for this
feature because the implementation details related to the testing via
that approach are a little too volitale.
Related to forem/forem#16842
* Updating copy based on forem/forem#16893
* styles
* styles
* dark styles
Co-authored-by: Paweł Ludwiczak <ludwiczakpawel@gmail.com>
