* Allow admins to visit spammers profiles and articles pages
* Added spam label to user profile and articles
* Unset cache control headers when providing admin access to spam content
* Removed unused comment
* Async append user suspended status pill
* Rubocop
* Relocate JS tests, for build & coverage
* Better error-handling for this controller
* Refactor HTML to render pill outside h1
* Continuing to tweak design
* JS class prepended
* add new org button in settings
* add support for mobile view
* remove varible for new org check
* fix design suggestions
* fix org settings test
* remove the settings for test since this text does not exists in user settings
* remove un-used copy
* Update class name
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Fix follow user spec
* fix the rspec test case
---------
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* remove presence validation for summary/url/proof, update UI
* simplify everything! use AR validation syntax
* Update app/models/organization.rb
revert reordering of url validation arguments. I had overcomplicated the work with a custom validation, and then upon resetting it, I changed the order unnecessarily
* feat: tests for series list on article page
* feat: test for jump to comments button (needs fix)
* feat: tests for reaction drawer on article page
* feat: test for full date on hover??
* feat: add full date on hover tests for all pages with publish dates
* fixed jumping to comments test
* move initialisers to packs
* fix coverage issues
* fix flaky login modal spec
* switch back to using onclick instead of addEventListener
* Fix bullet issue with includes commentable
* Flatten view logic
* Restore user comment section logic (but bullet-friendly)
* Try fixing podcast_episode -> podcast
* Add test that would have caught the logic bug
* View specs need describe to specific the path
* Remove unnecessary _comments argument
* Ooops, missed saving this
* Users can only opt-out of external ads
* Move random sampling out of FilteredAdsQuery
* Refactor filtered_ads_query_spec
* Add test for new permit_adjacent setting
* Rubocop
* Use permit_adjacent_sponsors on article sidebar and post-comments
* Remove, unused
* Update copy
* type_matched -> type_of_ads
* Remove non-applicable test
---------
Co-authored-by: Ridhwana <ridhwana.khan16@gmail.com>
* Initial setup work with error
* Dropdown working with error fixed
* Removed repition
* Home page billboard dropdowns added
* Created common file for dropdown
* Complete display ad dropdown usage
* Minor indentation fix
* Minor UI updates
* Minor test update
* Dropdown for billboard optimisation
* Added anchor tags
* Display ad unified code
* Design changes
* Design changes
* Changes to display ad click tracking
* Style changes
* Design change to admin display ad
* Nit fix
* Nit fix
* Updated test
* Fix connect account bug from settings
* Adds a controller concern test for after_sign_in_path_for
* Styling tweaks
* Merge uri query_values and only ignore i=i param
* remove unused stored_location_for and rename path var
* Reintroduce stored_location_for :p
* Reorder path origin priority
* Basic implementation of CTA in place of Recent Comments
* Updated & Added Tests
* Nit fix
* Test fixes
* I18n strings
* Changed UI in main feed too
* Fixed tests
* Nit fix
* Initialised tracking
* Allow trusted user to access response templates
* Add request specs for trusted user templates
* WIP: was just investigating...
* Move permission check to authorizer
* Revert "WIP: was just investigating..."
This reverts commit c38c60f7ab19ce43c174729c2542a9041e9322e2.
* Improved accessibility
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Prior to this commit, if the Forem limitted article creation only to
admins, when a new user would sign-up their call to action was to
"Create a Post". If that new user clicked on the button, they would get
an action unauthorized error.
With this commit, the call to action for Creating a Post is hidden to
that user.
The `users/onboardings/_task_card.html.erb` is rendered as part of the
home page. The home page, due to our [EdgeCacheSafetyCheck][1], does not
allow us to access attributes of the current user (e.g. are they an
admin); which means we can't add a `if policy(Article).create` to the
HTML erb. We must instead use the [`application_policy_content_tag`][2]
as well as the [AsyncInfo][3] to help inform the
[applyApplicationPolicyToggles.js pack][4] of the conditional rendering.
Closesforem/forem#17638
Related to forem/forem-internal-eng#347
[1]:8160089f3d/app/controllers/concerns/edge_cache_safety_check.rb
[2]:8160089f3d/app/helpers/application_helper.rb (L390)
[3]:8160089f3d/app/models/async_info.rb (L52-L61)
[4]:8160089f3d/app/javascript/packs/applyApplicationPolicyToggles.js
* Remove sustaining member newsletter, and its settings
This removes the concept of sustaining memberships from the system,
and logic related to or dependent on it.
This does not remove the monthly_dues column from the users table (todo).
* Remove unused newsletter setting
Since nothing accesses the mailchimp_sustaining_members_id setting,
it's safe to remove.
* Use destroy rather than delete to ensure settings cache is cleared
We have a callback in Settings::Base to clear the cache after commit,
I assume it's useful to trigger that. This requires destroy, not
delete, to be called.
Prior to this commit, only those who could create posts could edit their confi
However, we are allowing users who can't create posts to edit posts. So
we want to allow for them to change their editor configuration.
Revisits
- forem/forem#16516
Supplants
- forem/forem#16778
Related to
- forem/forem#17123
- forem/forem#16908
* 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>
* Authorize Web Monetization If User Can Create Article
There are three things I'm introducing in this PR:
1. Extracting a partial
2. Reworking the i18n keys
3. Adding a policy check regarding Web Monetization
In *extracting a partial*, I'm following the existing pattern where
other extensions have their own partial.
In *reworking the i18n keys*, I'm ensuring that the keys are part of the
same namespace. This will make finding their usage easier. Further, if
we decide to remove (or convert to a plugin) the web_monetization, then
we're just a bit closer to that possibility.
Last, and the reason for the work, is *Adding a policy check regarding
Web Monetization*. This follows on the work in forem/forem#16790.
Closes forem/forem#16820
Related to forem/forem#15098
There are two things to test:
1. Does the feature flag work or not.
2. Are the i18n keys properly applied.
For the feature flag:
- checkout this branch
- in rails console `FeatureFlag.enable(:limit_post_creation_to_admins)`
- start the rails server
- login as a non-admin user
- go to /settings/extensions and scroll to the bottom, you **shouldn't** see
the partial
- login as an admin user
- go to /settings/extensions and scroll to the bottom, you **should** see
the partial
Or visually verify the relatively simple change (and accept that it
conforms to #16790's existing pattern).
For the i18n keys, I have a before screenshot (from DEV.to) and the
after (from the changes on this branch).
* Adjustments based on contributor feedback
