* feat: remove feature flag on the member index view and re-arrange some partials
* feat: remove Feature Flag for the invitations view
* feat: remove Feature Flag for the gdpr view
* feat: remove Feature Flag for the controls
* feat: remove the feature flag in the tests
* remove extra queries that we no longer use
* Update app/views/admin/invitations/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/admin/invitations/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/admin/users/index/_controls.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/admin/users/gdpr_delete_requests/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update cypress/integration/seededFlows/adminFlows/users/userIndexView.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update cypress/integration/seededFlows/adminFlows/users/userIndexView.spec.js
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/admin/users/gdpr_delete_requests/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* feat: attempt to fix Cypress test
* fix: soem other cypress tests
* fix: search bar
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
From Anuj:
> Going forward we will be using heavy font-weight for the titles of all
> the admin sections. So it’s good consistency-wise.
This resolves that issue.
Closesforem/forem#17327
This div tag is subsumed by the line below (e.g. `<%=
application_policy_content_tag("div"...`). When the unclosed div is
present there is some undesirable layout offset. When it's removed,
things line up a bit nicer.
Discovered while attempting to reproduce forem/forem#17324
* add expandable search control at mobile size
* add invitations smaller layout
* replace missing member image
* tweaks following merge
* minor layout tweaks
* add actions to smaller view, update cypress specs
* 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>
* feat: add the export route
* feat: base export csv
* refactor: move the svg into its own file
* feat: add the export partial
* feat: export teh correct fields etc. for the csv
* user status helper
* feat: ensure that we format the time
* feat: add a spec for the CSV
* remove space
* remove puts
* chore: remove blank space
* feat: update traits
* Update app/views/admin/users/export.csv.erb
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
* Update spec/requests/admin/users/users_export_spec.rb
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
* Update spec/requests/admin/users/users_export_spec.rb
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
* fix: export should not error for unregistered users
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
* Adding logic to hide Create Post on empty dashboard
As implemented, folks won't see this page if they can't create a post.
However, as our implementation drifts, we should continue to apply the
same policy.
See forem/forem#16999 for the conditional logic that redirects users.
* Adding a hack to fix a unit test
* 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
* Adjusts Member Index View tooltips to include resource type
* Adds .compact to the list of resource_types in #format_role_tooltip
* Updates users_helper.rb#format_role_tooltip tests
* right align tooltip
* Update app/views/admin/users/_member_index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* add an xl breakpoint and use in member index view
* expand search controls at medium breakpoint
* tweak small screen layout options per breakpoint, add overflow button
* small fix
* switch where role appears depending on breakpoint
* adjust for smallest layout
* tweaks for medium layout
* tweaks for large layout
* tweaks for XL table
* 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>
* Adding link to Spaces admin guide
This commit presently links to a missing page, but in consultation with
Ella, she'll be putting the page at the linked URL.
The original copy was:
> Want to learn more about spaces? Check [Admin Guide]
I chose to go with the following, as assistive technology will announce
the link's text as "more about Spaces in the Admin Guide", which I find
more a11y oriented.
> Learn [more about Spaces in the Admin Guide]
Closesforem/forem#17148
* Update app/views/admin/spaces/index.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Bringing the Learning inside the Linking
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Prior to this commit, we always assumed a policy based attribute would
have the "hidden" class and then we'd rely on JavaScript to toggle the
visibility.
With this approach, we are "cheating" a bit by specifically referencing
a feature flag that is the driver for the visibility behavior.
This mirrors the one-off behavior of forem/forem#16606. Namely, when
the flag is off, we render without default hiding. And when it's on, we
include the "hidden" attribute.
In both cases, we will still leveraged the [applyApplicationPolicyToggles.js][1]
introduced in forem/forem#17076.
An impact could be that if multiple flags are fiddling with the policy,
we could see an area disappear or wrongly remain present. This would be
a warning to fix (the server would still enforce correct policies so
this would be a bit of a "heads up we have a mismatch in understanding
that happens to impact UI behavior").
[1]:https://github.com/forem/forem/blob/main/app/javascript/packs/applyApplicationPolicyToggles.js
* Adds data to the member column in Member Index View
* Adds roles, statuses, and latest activity to Member Index views
* Adds the list of orgs a user belongs to in Member Index view
* Updates the image URL to link to each users member detail view
* Adds comment_suspended to user current_status and makes roles prettier
* Fixes bullet warning and encapsulates org logic in method
* Properly displays today and yesterday in words
* Refactors #current_organizations to use ternary
* Updates user.rb Member Index View-related methods
* Adjusts the styling of user roles and adds tooltip to roles
* Updates Member Index View to be mobile-friendly
* Updates userIndexView.spec.js
* Updates capitalization within userIndexView.spec.js
* Updates Member Index View per mobile designs and feedback
* Adds member status logic inline with SVGs
* Updates the status column for mobile layout
* Adjust current_role tooltips for Member Index View
* Adds organization name tooltip to member orgas
* Adds organization pics to Member Index View and cleans up helpers
* Addresses PR review feedback (Thanks, Suzanne!)
* Uses CSS in place of SVGs for member statuses
* Adds E2E test for and removes link to org page from Member Index View
* Addresses PR feedback comments by refactoring Member Index View code
* Removes leftover code in user.rb
* Update method that tooltips rely on
* Spells regular correctly :
* Adds a spec that tests Admin::UsersHelper#format_last_activity_timestamp
* Adjusts #cascading_high_level_roles logic and roles
* Adds a spec for #cascading_high_level_roles
* Adds a #last_activity spec to the User model
* Adjusts code a bit per PR feedback. Thanks, Ridhwana! :)
* Updates specs for Member Index View helpers
* Adds Timecop.freeze to help with timestamp failure in user_spec.rb
This commit adds instruction as to what's happening when a person
toggles on this feature. So as to not repeat knowlege, I added a
`NUMBER_OF_MINUTES_FOR_CACHE_EXPIRY` constant so the UI can reference that
instead of dropping a hard-coded 15 in the UI.
Closesforem/forem#17097
When a user does not have any posts NOR can they create posts, we are to
hide the "Search > My Posts" section.
I have chosen not to write a test for this as it's exercising a well
tested policy and we don't have a unit test for this view. As part of
forem/forem#17076 I introduced some cypress tests. But that feels like
quite a bit of overkill for this feature.
Closesforem/forem#16837
Related to forem/forem#16821
* 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>
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
