* Require profile fields to belong to a group
Remove the empty group dropdown from the group select tag
Remove the optional: true from the belongs_to validation (raise a
validation error on save if the group is not provided)
Update test to remove belongs_to's optional setting
* Update ProfileFields::Add spec to include profile field group
* update factory to ensure a non-empty profile field group
* Add required profile field group to seeded profile fields
Since profile field is required, create was failing (silently).
Add required field so these are available in e2e tests.
* Use factory `association` to create a profile field group
https://github.com/thoughtbot/factory_bot/blob/master/GETTING_STARTED.md#explicit-definition
* provide required profile field group when posting data
* Fix one spec, drop another
Both of these scripts will be removed in the other branch (changing
the attribute name) - dropping the test here seems lower trouble than
modifying an out of data data update script to pass.
* skip test slated for removal
Similar to the last commit - this test exercises a script about to be
archived in the other branch.
* Fix tall aspect-ratio images getting squashed
When the `max-height` kicks in, the `width` attribute needs to be overridden, just like `max-width` needs `height: auto`.
* Prefer `object-fit` to `width`
Avoids clashing with GIF-pausing library that sets `.ff-container`
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Prior to this commit, I saw the following in the Rails test log:
```
DEPRECATION WARNING: 'include Pundit' is deprecated. Please use 'include Pundit::Authorization' instead.
(called from include at ./app/controllers/application_controller.rb:12)
```
* move script to packs, strip ids
* make sure userdata is available before determining ui
* stop working around old html, fix duplicate ID errors
* skip login modal
* remove DEV hard coding
* replace system spec with cypress spec
* update base_data to include apple auth info, add to cypress tests
* add initial version of DUS to resave HTML
* remove data update script
* Removing Articles::Builder making policy decision
This change is a refactoring through triangulation. Given that
`ArticlePolicy#new?` returned true, I'm prepared to assume that calling
`authorize(Article)` in all cases is acceptable.
So to narrow the Builder making a policy decision I renamed the returned
value to reflect what it was actually doing in the logic. And in
renaming, flipped the polarity of the boolean. Why the flip? Because
`needs_authorization == !store_location`.
In consultation with Allison and Jennie, I'm proceeding with a short-cut
to get me unstuck. That unstuck is namely "I need to ensure that the
articles#new action can go through authorization."
Given that I'll be spending time in the authorization layer, I hope
these noted short-cuts and comments will be useful in future spelunking
efforts regarding authorization.
Closes#16529
* Update app/policies/article_policy.rb
Co-authored-by: Michael Kohl <me@citizen428.net>
* Disabling spec
* Update app/policies/article_policy.rb
Co-authored-by: Dwight Scott <dwight@forem.com>
* Update app/policies/article_policy.rb
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Michael Kohl <me@citizen428.net>
Co-authored-by: Dwight Scott <dwight@forem.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
* quick fixes on the overview page
* more overview fixes
* put stats in a descrition list
* fix error in twitter link
* fix some more svgs
* disable the remove tag pills
* link description in merge user modal
* link some other descriptions
* prevent duplicate IDs in edit org description label
* fix badly resolved conflict
* updates after merged changes
Our domain of "admin?" method names is already a bit confounding. The
policy methods renamed the existing Policy::Authorizer methods, and
further obfuscated and confused intention.
This refactor aligns the policy methods with the Policy::Authorizer
methods. It is a non-breaking change, but one that may add warnings in
the logs. If you see those, resolve them per instructions.
Related to #16483
Prior to this commit many of the policy methods were of the form:
```
def create?
edit?
end
```
The above works, but introduces a place for code drift.
We can shorten this to:
```
alias create? edit?
```
This helps keep the policy methods compact and scannable. All things
authorization policy related should create narrow surface areas. By
hand-crafting methods, it is easier for "slippage" to occur.
Another advantage of `alias` is it's use is reflected in API
documentation. With alias you need only write documentinig comments for
one method and the doc generators will relate the alias and the original
method.
If you "hand craft" a method using explicit delegation, the API
documentation won't pick up that two methods are aliases.
Further, I believe we should be moving towards parity between the
GET/POST/PUT methods that are related (e.g. the create/new pair and the
update/edit pair). This is not the case, as we "silently" suspend
folks. As we move through the [authorization work][1], we will start
hiding the links/buttons when a user can't take the action.
Related to #16483 and #16523
[1]:https://github.com/orgs/forem/projects/46
* Removes code behind new_admin_members feature flag
* Removes components/admin/users/tools/* and the tools components
* Removes unused /admin/users/tools/* controllers, comments, and routes
* Removes New Member View-related E2E and RSpec specs
* Remove admin_users_tools.rb frin spec/support/shared_examples/
* Removes remaining component-related specs
* Removes the view_component gem and test helper
* Resolve merge conflicts in Admin::UsersController
* Removes the view_component gem, as it is no longer used
* Removes view_component from Gemfile.lock
As written in the comments, we're looking at making the smallest change
to deliver on the feature. The other goal is to move from our
`user.admin?` paradigm towards leveraging Pundit policies.
If we need to move beyond Pundit, it will be easier once we've moved
all of our `user.something_something?` to policy questions. And please
note, I don't know if we'll move past pundit.
See [Authorization System: use case 1-1 project][1] for details on the
project.
Closes#16483
[1]:https://github.com/orgs/forem/projects/46/views/1
This is the least effort I can presently think of to allow for us to
reprocess user article's and handle the scenario in which the user may
have once had permission to the liquid tag but no longer.
This DI is not something I imagine using, but may highlight a better
approach for liquid tag permissions.
Related to #12146 and #16460
