* Try renaming moderator -> super_moderator
* Still finding 'moderator' words
* Fixes for failing specs
* Update test with new role name
* Update app/services/moderator/manage_activity_and_roles.rb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Article query spec for scheduled articles
* Added scheduled article badge on the user dashboard
* Added published_at field to editor options
* Accept and validate published_at from editor
* Refactor published_at validation
* Allow 1-minute difference in published_at
* Notice on an unpublished article page
* Added specs for 'Click to edit' link on scheduled article preview page
* ContextNotification model
* Articles::Publish worker
* Added specs for articles publish worker
* Schedule publish articles worker
* Added tests to check for scheduled posts in feeds
* Don't allow managing scheduled articles
* Don't send notifications for scheduled articles
* Set published_at in Articles::Updater when publishing
* Published_at value in post options
* Pass timezone and set published_at accordingly
* Limit setting published_at to the future
* Readonly published_at for articles that were already published
* Chagning published_at format in editor v1 (start)
* Changed published_at format in frontmatter, specs
* Added specs for updating published_at from frontmatter
* Fixed accepting past published_at for articles published_from_feed
* Enabled published_at validation: don't allow updating published_at for already published articles
* Validate published_at on create
* Added a spec for updating published_at for exported articles
* Fixed specs related to creating articles with past published_at
* Fixed specs related to past published_at for articles
* Added a hack so that admins would be able to update published_at
* Switch button text schedule/publish when changin publishedAt
* Fixed saving published_at with timezone
* Added a feature flag for scheduling articles
* Default text in markdown editor depends on feature flag
* Enable article editor cache again
* Fixed the default value in the markdown editor
* Fix sitemaps spec
* Removed tooltip
* Fixed articles update specs
* Added missing locales
* Fixed article create specs
* Fixed spec
* Removed commented code
* Returned enabling extensions in the schema
* Returned accidentally deleted constraint
* Make articles query spec more stable
Co-authored-by: Jeremy Friesen <jeremy.n.friesen@gmail.com>
* Removed commented code
* Removed unused code
* A clearer policy
Co-authored-by: Jeremy Friesen <jeremy.n.friesen@gmail.com>
* Use StringInquirer for article current state
* Added a note and todo to articles factory past trait
* Remove duplicated PropType
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Refactor query in the Articles::PublishWorker
Co-authored-by: Mac Siri <krairit.siri@gmail.com>
* Refactor articleForm.jsx
Co-authored-by: Mac Siri <krairit.siri@gmail.com>
* Removed specs that are no longer relevant
* Removed useless onKeyUp on a hidden input
* Refactored articleForm
* Hide scheduling from post options when published_at is readonly
* Run sends notifications worker every 5 minutes instead of every minute
Co-authored-by: Jeremy Friesen <jeremy.n.friesen@gmail.com>
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Mac Siri <krairit.siri@gmail.com>
The [`ArticlePolicy#moderate?`][1] method answers the questions around article
moderation.
At present this change does not introduce any significant changes (aside
from the JS logic loop). The next "step" is to adjust the
`ArticlePolicy#moderate?` method to test if the user has a moderator
role.
Further, we'd need to see what is available on the action panel.
Related to forem/forem#17606
[1]:5ac3216a5a/app/policies/article_policy.rb (L160-L174)
Prior to this commit, if we didn't have an instance of `Article` we
likely had the class `Article`; we would then run a potentially VERY
expensive query (`SELECT user_id FROM articles;`) to provide an
answer; namely if all of the articles are written by the same user then
yes this user is the author.
With this commit, when you're authorizing the `Article` class, let's
just say "Nope, this user isn't the author".
Closesforem/forem#17604
* 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
Prior to this commit
This would have been a bug, if someone had:
1. Toggled on the :limit_post_creation_to_admins feature flag
2. Wasn't an admin
3. Already had a published post
4. Went to edit the post and attempted to preview it
Related to the following issues:
- forem/forem#16908
- forem/forem#16944
- forem/forem#16837
- forem/forem#16942
* 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 commit does three things:
1) Adds and tests the ArticlePolicy#moderate? feature
2) Refactors the spec helpers to be a bit more flexible
3) Adds a few more edge case tests around ArticlePolicy
My apologies for conflating these changes, as it makes this commit
more challenging to review.
The goal is to adequate demonstrate the logic around users who can or
cannot moderate. At present, the rules for who can moderate is here:
841491c6ee/app/javascript/packs/articleModerationTools.js (L17-L27)
```js
if (user?.trusted) {
if (user?.id !== articleAuthorId && !isModerationPage()) {
initializeActionsPanel(user, path);
initializeFlagUserModal(articleAuthorId);
// "/mod" page
} else if (isModerationPage()) {
initializeActionsPanel(user, path);
initializeFlagUserModal(articleAuthorId);
}
}
```
- Related to forem/forem#16783
- Closesforem/forem#16784
Videos are a conceptual subset of Articles (see
[VideosController#create][1] for supporting "evidence"). As such, we
want to ensure they conform to the expectations of the ArticlePolicy (as
described in forem/forem#16483).
This feature enhancement does a few things:
1. Renames swaps the `VideoPolicy#new?` and `VideoPolicy#create?`
declarations (reversing the alias direction)
2. Moves methods out of the concrete ArticlesPolicy into the
ApplicationPolicy.
3. Exposes these user oriented methods for external
consumers (e.g. making future refactoring work easier). The happy
benefit is that this already removes a bit of duplicated logic.
4. Highlights that while yes the Policy is correct, we also may be
flirting with the concept of some sort of User "properties as it relates
to authorization" logic (good standing users, established users,
etc.)
5. Reworked the timing of a guard clause and setting of instance variables.
[1]:
33e9bac0f7/app/controllers/videos_controller.rb (L18-L22))
Relates to #16483Closesforem/forem#16728
To test this, I'm relying on the existing test suite. I envision that
shifting from returning false for suspended users to raising an
exception might cause some false positive errors. Note, in the
[AppliciationController][2] we handle the responses. Paired with
[config/appliciation.rb][3], we handle the policy exceptions.
[2]:33e9bac0f7/app/controllers/application_controller.rb (L32)
[3]:33e9bac0f7/config/application.rb (L71-L81)
* Only fetch RSS of users who can create articles
This commit leverages changes from forem/forem#16732 and
forem/forem#16763 to ensure that we're only fetching RSS feeds for
folks who have permission to create articles.
In addition, I chose to rename the variable `user_scope` to
`users_scope` to bring consistency in the variable names.
I also chose to refactor a private method so that it wasn't setting two
instance variables but was instead returning a value that could be used
to set an instance variable.
Closesforem/forem#16487
* Amending method name
As I'm looking at limiting feed fetching only for users who are able to
create articles, I needed a means of querying "Who are the users who can
create articles?" This bit of work was the smallest chunk that I could
think of.
These kinds of questsions are going to propogate (e.g. give me a list of
all the people who can comment? who can create articles in this space?)
For now, this pattern should suffice.
Yes, there's duplication of knowledge between the policy's instance
method and class method. And there's a bit of knowledge bleed between a
user's method (e.g. `user.any_admin?` and
`*Authorizer::RoleBasedQueries::ANY_ADMIN`) but that's a small "evil".
Related to #16486
* Adjusting ArticlePolicy for admin only posting
The goal of this commit is actually two fold:
1) To add documentation regarding my current emerging understanding of
our caching implementation as it relates to our authorization and
authentication.
2) Flippiing "on" the feature's core authorization check.
Buried within this is the desired normalization of the authorization
between the `ArticlePolicy`'s `#create?`, `#preview?`, `#new?`.
My testing plan for this is to ask for SRE to spin-up a canary, then
test. What does that look like? I'm uncertain because this is nudge
closer towards our edge-caching strategy. Which makes robust testing
more difficult.
Closes forem/forem#16483
Related to #16529, #16571, #16536, #16529
Informs #16490, #16606
* Update spec/requests/editor_spec.rb
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
Co-authored-by: Jamie Gaskins <jgaskins@hey.com>
* Initial hack
* Begin functionality implementation
* Add proper route
* Finish up
* Fix test and formatting
* Fix test vars
* Update app/views/moderations/actions_panel.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/moderations/actions_panel.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/views/moderations/actions_panel.html.erb
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Update app/controllers/articles_controller.rb
Co-authored-by: Michael Kohl <me@citizen428.net>
* Update file to not use keys that are not needed
* Finalize featured logic
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
Co-authored-by: Michael Kohl <me@citizen428.net>
* 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>
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
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
* Create DiscussionLocks
* Fix specs
* Update nullify_blank_notes_and_reason
* Update before_validation call
* Updated DiscussionLockPolicy for clarity
* Move permitted_attributes to a constant
* Update route
* Apply suggestions from code review for frontend
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Add title tags
* Wrap unlock confirm in main element
* Wrap flash messages up in div
* Actually fix title tags
* Hide comment reply button when discussion is locked
* Add E2E tests
* Try to fix E2E tests
* Cypress...you work locally but not in CI...why!?
* PR feedback
* Update E2E tests
* More E2E updates 😭
Co-authored-by: Suzanne Aitchison <suzanne@forem.com>
* Rename banned and comment_banned roles
* Add data update script to rename roles containing 'ban'
* Add named error for Suspended users
* Update unidiomatic method names
* Rename misc banned to suspended
* Apply suggestions from code review
Co-authored-by: Michael Kohl <me@citizen428.net>
* Add unit tests for suspended methods
This commit also adds TODO comments for removing banned and
comment_banned from the codebase after data update scripts have
successfully run on all of our Forems.
Co-authored-by: Michael Kohl <me@citizen428.net>
* Add /stats endpoint for articles, opened only to Pro users
* Add analytics to article stats page
* Add stats button to the article page and test stats page
* Allow user to have many orgs
* Allow users to handle multi orgs in settings
* Make rounded buttons inline
* Add multi org function to dashboards
* Fix merge conflicts
* Fix mistake in merge conflict fix oops
* Display the correct membership level
* Fix accessibility issues
* Display organizations for article editors
* Handle submitting org id with preact editors
* Make listings work with multiple organizations
* Allow listings to have multiple orgs on create
* Display the correct number of credits for each org
* Move script tag to Webpack
* Allow multi orgs for purchasing and viewing credits
* Use OrganizationMembership as authorization check
* Display multiple organizations for notifications
* Allow dashboard to be viewable under multi-orgs
* Remove unused method
* Add multi-org functionality for article editors
* Show pro dashboard buttons for member+ org levels
* Leave the correct organization
* Allow article API to change org id
* Add left-out authorization method oops
* Make nav buttons a bit more clear
* Fix merge conflict
* Fix adding org id for /api/articles and tests
* Fix tests for org policy
* Use proper logic for displaying org members
* Update org actions with new authorization
* Use correct org when creating a listing
* Remove additional payment charge oops
* Mark org notifications as read with authorization
* Remove deprecated post_as_organization attribute
* Use new org_admin syntax
* Remove deprecated org logic for article create and update
* Default all RSS posts to not belong to any org
* Render org_member page for guest users
* Update org policy spec to work with multi orgs
* Use org_membership for org traits and move identity code
* Use org_member trait
* Update to work with multi-orgs
* Validate article's org_id if param org_id is blank
* Make a let variable
* Remove unnecessary eager load for credits
* Fix HTML structure and org logic for non-org users
* Update credits spec for multi-org
* Add test for failed payment when purchased by org
* Lint listings_spec
* Test that the listing was created under the user
* Add tests for POST /listings multi-org
* Use double quotes for classes
* Fix /manage and a few other multi-org bugs
* Fix test for multi org
* Use correct method SQL exists? not Rails exist?
* Fix reads spec for multi-org
* Fix org_controller actions to work with multi org
* Test only multi org and not old usage and fix leave_org
* Fix org showing user profile img test for multi-org
* Fix org logic for users with no orgs
* Remove switch org functionality
* Update tests and add hidden param for org id
* Redirect to the specific organization
* Test other org button actions
* Use settings_notice instead of legacy notice and refactor
* Fix weird extra end issue prob from merge conflicts
* Test for with new flash key
* Fix user_views_org tests for multi-org
* Test for new flash message
* Update snapshot with new a11y html
* Move styling to stylesheet
* Add site admins functionality
* Move org_member? method in user model and refactor
* Use unspent_credits_count for organizations
* Add tests for /listings/new and minor bug fixes
* Use .present? in case of empty array
* Fix a lingering deprecated method
* Use greater than 1 for random numbers
* Add tests for counting spent and unspent credits
* This commit adds the "archived" attribute to the Article model, which will
enable users to automatically filter archived articles/drafts from appearing
on their dashboard. It also adds an ellipsis menu with a link to archive the
article. I've also moved the Mute Notifications button into the ellipsis menu
as well.
* Add ellipsis menu and make it work
* Fix logic error
* Hide ellipsis menus when you click elsewhere on the body
* Extract function to remove duplication
* Ensure that menu is hidden when the ellipsis button is clicked on an open menu
* Ensure that archiving post button works and that 'archived' param is accepted by the controller
* Enable link to toggle showing/hiding archived articles
* Make 'mute' and 'archive' buttons in ellipsis dropdown list work
* Refactor to make Code Climate happy
* Minor JS refactors
* Remove deprecated analytics role
* Make anchor tag a bit more readable
* Add OrganizationMembership table and model
* Add organization_membership associations
* Add unique indices for user_id and org_id
* Wrap update and create calls in transactions
* Remove specs of deprecated analytics_beta_tester
* Use a slightly faster call for user_id
* Remove unused file
* Test receive notifications functionality
* Notify when receive_notifications is true
* Test receiving reaction notifications
* Do not notify if receive_notifications is false
* Fix test for parent comment notification
* Add article mute notifications feature
* Remove deprecated specs
* Prevent email when receive_notification is false
* Update button messaging
* Use RESTful /article_mutes patch request
* Use parent or root article instead
* added organization policy + spec
* user specs for is_org_admin?
* added authroize to organization controller
* admin policy + specs
* deleted enforce admin due to pundit policy redundancy
* applied admin policy to entire admin namespace
* refactoring analytics controller WIP - wanna test codeship
* Add protection against reactions to unpublished articles (#473)
* Add chat channel policy and spec (#474)
* Add comment policy and specs (#475)
* Fix edge case with apostrophes
* Add comment policy and specs
* Add login for deleting comment spec
* Change test to raise pundit error instead of 404
* Clean up comment destroy request specs
* Remove redundant raise
* Whitelist columns on to_json call (#477)
* Add pundit policy for several controllers (#476)
* Add pundit policy for several controllers
* Adjust video spec
* Fix tag request specs
* Add proper twilio tokens request specs
* Remove puts statements
* Add a couple basic request specs (#478)
* Add a few tests and fix user tag color bug (#482)
* Refactor handle_tag_index in stories_controller (#481)
* Modify valid_request_origin? (#483)
* Add misc specs and remove banned attribute from user model (#484)
* Fix missing Cloudinary tags and misc specs (#486)
* removing current_user_is_admin? to use .is_admin? method
* added missing org policy routes
* Add comment for all public controllers
* Fix edge case for test
* Authorize mod controller and add specs
* Refactor methods via inheritance and use only super_admin role
* Create policy method for analytics via article_policy and refactor
* Capitalize all buttons in dashboard page
* Fix org tests and remove old admin test
* Use only happy path for analytics
* Fix tests to use Pundit error
* Update org_policy spec
