* Make ahoy_email default_options[:click] an env var
* Also noted a typo here
* Manually mount AhoyEmail::Engine
* Disable by default
---------
Co-authored-by: Mac Siri <krairit.siri@gmail.com>
* Adjust Digest Email design and configuration
* Adjust some tests
* Update tests
* More adjustments to markup and tests
* More adjustments to markup and tests
* Digest email feature flag
* Test title variants
* use HTTP_CLIENT_GEO in billboards show action
* limit targeting to signed in users
* re-add cypress test
* simplify billboards request spec
* fix header problems hopefully?
* whoops
* Squash filleduchaos/caching-billboards-by-location
* export ISO 3166-2 regions
* wip
* remove ISO 3166-2 regions
* finally, a VCL config that...works?
* update billboard controller & specs
* fix specs
* clean up and document VCL some more
* remove vcl_init sub
* remove billboard fragment caching
* Rebased with main
* Footer visibility bug fix
* Minor fix
* Added tests
* Removed initializeFooter as it is not working as expected
* JS code updated as per suggestion
* Updated cache details
* Rebased with main
* Minor fixes
* Minor fixes
* Update .github/ISSUE_TEMPLATE/-core-team-only---new-approved-feature.md
* Update .github/ISSUE_TEMPLATE/-core-team-only---new-approved-feature.md
* Update .github/ISSUE_TEMPLATE/-core-team-only---new-approved-feature.md
* Update .github/ISSUE_TEMPLATE/-core-team-only---new-approved-feature.md
* Update .github/ISSUE_TEMPLATE/-core-team-only---new-approved-feature.md
* Update .github/ISSUE_TEMPLATE/-core-team-only---new-approved-feature.md
* Removed JS logic
* Nit fix
* migration init
* create an initializers directory
* remove console log
* migrate localDateTime functions and remove comment date from asset pipeline
* add unit test
* add one more
* year test
* baseTracking pack
* Define dataLayer
* disable unused var
* disable another unused var
* remove initializer call from base of asset pipeline
* remove asset pipeline baseTracking file
* Pages API pt 1 (read/get/index+show)
* Update spec/requests/api/v1/docs/pages_spec.rb
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Update spec/requests/api/v1/docs/pages_spec.rb
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* API Key not required for index & show
* API Feature flag has long since been removed
* Page schema
* Fix spec broken by merge
Co-authored-by: Ridhwana <Ridhwana.Khan16@gmail.com>
* Minor fixes
* Replaced justify-content-between with justify-content
* Override all heading tags, paragraph tag
* Fixed a tag underline css
* Removed bootstrap library
* Removed duplicate crayons-select class
* refactor: move trackEvents to a utilities folder so that it can be re-used
* feat: add a function called trackCommentClicks and use it on the articlePage
* feat: update the auth widget to take the correct properties
* feat: add create account tracking method for hamburger
* feat: add create account tracking method for sidebar left
* feat: whoops, sidebar tracking info added
* feat: add the feed card create account tracking
* feat: whoops add the id to the dom
* feat: add top nav create account tracking
* feat: create account tracking for the registration modal
* fix: callback instead of invoking + rename class
* fix: js-prepend
* feat: some showLogin event tracking
* use the tracking propert
* x - feed.jsx
* fix: oops I removed hidden
* track from the search login
* feat: add tracking for follow button
* fix: main_stories is only being called in view/articles and both are including the FollowButtons pack
* comments track
* feat: remove punc (.)
* chore: cahnge working
* chore: remove tracking-id from modal
* feat: remove ecmascript features
* refactor: rename some events
* feat: referrer page
* feat: add a secondary source for the follow buttons
* feat: remove file that is not used
* chore: rename key
* feat: use @utilities
* feat: add spec for create account clicks
* feat: add key referrer
* fix: tests
* fix: oops
* chore: add commented test
* test for tracking
* feat: update the change by 1
* feat: aggregate_failures
* feat: add data-no-instant back
* feat: try a different way of testing
* refactor: change secondary_source to referring_souce
* feat: change ahoy event test
* feat: add a version number to ahoy tracking
* feat: change the href to pathname
* feat: reply comment tracking
* fix: to be present syntax
* feat: use href instead of pathname
* chore: do not track tags and podcasts follow and remove referrer
* feat: add readinglist
* fix: remove referrer from test
* feat: fail gracefully in instances where there is no tracking data
* fix duplicate ID main nav
* fix duplicate ID other nav headings
* fix duplicate ID reading list count
* fix duplicate attribute class
* missing case readingCountList on feed
* missing dot in query selector
* Revert "fix duplicate ID other nav headings"
This reverts commit 4f495962c47e08f0f6c41e33e897b2db176432f5.
* use generic class 'other-nav' for tests
* pass a variable 'context' to the partial nav
* pass var 'context' to partial
* fix unwanted typo in partial sidebar
* Update app/views/admin/navigation_links/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/assets/javascripts/initializers/initializeReadingListIcons.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/assets/javascripts/initializers/initializeReadingListIcons.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* js-reading-list-count renaming
* use data-testid instead of generic classes for tests
* fix typo in specs
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Encapsulating the "why we hide/show" something
Prior to this commit, we were relying on our views/templates to
understand why it might want to append the "hidden" dom class. That is
not ideal, because it required repeating knowledge about the conditions
of the policy outside of the policy's domain.
With this commit, we're removing a duplication of knowledge; or more
appropriately asking the steward responsible for the knowledge to
produce the answer.
* Refining the note to not describe a course of action
* Revert "conditionally render create post button for admins #16490 (#16606)"
This reverts commit 1cb45995cb.
* Adding conditional create post rendering
This pull request does two things:
- Reverts the forem/forem#16606
- Replaces the conditional rendering with the approach from forem/forem#17076
What to consider:
- How does this impact Cumulative Layout Shift (CLS). Prior to this
commit, we didn't "flicker" the "Create Post" button into view if the
site didn't have the conditional.
- In reverting forem/forem#16606 we remove a dependency on Turbo.
- We reduce one network call, relying instead on the async_info to carry
the visible/hidden logic.
If the "flicker" is a problem we could add a conditional in the page for
if the site has enabled that feature. However, that's a place holder as
we're looking at possible other reasons for allowing/disabling the
create a post.
This is a non-blocking PR, as in we can merge or not merge this and
proceed with what we have. Instead the main goal is to "unify" our approach.
* Update cypress/integration/seededFlows/policyFlows/limitPostCreationToAdmins.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Leveraging change from forem/forem#17143
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* WIP - Conditional rendering of "Create Post" link
This PR builds on the conversation from forem/forem#17056 and moves in a
slightly different direction.
Important in all of this is that the ability to create a post is
enforced on the server. If the "Create Post" button were to be visible
but the user couldn't create a post when they clicked the button, they
would get an authorization error (or some such response).
This PR posits a different and perhaps competing approach to
forem/forem#16606. This PR provides a general approach in which we add
class attributes in our HTML erb files.
Note: I have not included Cypress tests as I don't want to yet commit
that time. I'm also wondering if this is the "right" thing to do. I
definitely think we want to add some JS tests. But could we do JS and
unit tests? (How do we reach consensus regarding our test approach?)
Again, thank you for the conversation and expect an even more "complete"
PR after we have our discussion.
* Extracting AsyncInfo model to ease testing
* Renaming forbidden to visible
* Adding cypress test to assert no 'Create Post'
These are always treacherous. What happens when we rename the button?
The test will continue to work.
* Apply suggestions from code review
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Switching to pack file for policy
Follows on [Suzanne's comment](https://github.com/forem/forem/pull/17076#issuecomment-1088567286)
* Update app/javascript/packs/applyApplicationPolicyToggles.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Trigger Build
* WIP - use turbo to render html for create post button
todos and discussion topics
[] add tests (probably gonna be a lot of cypress 😅😭)
[] nominclature & file structure for authorization controller/routes
[] is this "authorizations" namespace approach the best?
[] authorization strategy relies on current user and caching doesn't
like `current_user`
* Use URL helper and not change the policy just yet
* put the turbo frame behind a feature flag
* Trigger Build
* Use URL helper and not change the policy just yet
* :)
* Add some test coverage and use same feature flag for consistency
* rubocop
* more rubocop
* trigger build
* adding a small sleep to see if specs pass 😩
* remove sleep
* disable Turbo session drive
* WIP
* Revert "WIP"
This reverts commit ce838672069fd703122156a0d82e5e6ad5398e0a.
* Moving spec from dashboard to root
With forem/forem#16913 the underlying test broke because we were
redirecting on the dashboard.
Co-authored-by: Jeremy Friesen <jeremy.n.friesen@gmail.com>
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.
* Focus flash message button on load
* update specs
* Update app/javascript/packs/admin/flashMessages.js
Co-authored-by: Nick Taylor <nick@iamdeveloper.com>
* Update app/javascript/packs/admin/flashMessages.js
Co-authored-by: Nick Taylor <nick@iamdeveloper.com>
Co-authored-by: Nick Taylor <nick@iamdeveloper.com>
* remove IE6 XHR support
IE7 and later support XMLHttpRequest natively, and most of the rest of
the code base uses fetch() which may not work in any version of IE
Drop the conditional here in the assumption that this would only be
the first of many problems for a user with an unsupported browser.
Prior to this commit we had an inline logic check on whether or not to
render a navigation link. As we are looking to rollout the feature flag
for Listings, we needed to add another somewhat complex conditional.
This commit moves the inline conditionals to a helper function, which
makes testing the logic far easier. Especially since we need to bombard
the tests with the combination of 3 different boolean checks. (And one
of those boolean checks requires even more but could be stubbed).
There should be no UI differences, as we're presently assuming the
Listings feature is enabled.
Related to forem/rfcs#291
