Roadmap for version 1.0 🎉

[valscion]

This is a roadmap for getting to version 1.0.

• [Authorize relationship actions with custom policy methods #40] Allow authorization of relationship operations separately
• [Add tests for every scenario of the relationship operations #47] Add exhaustive tests for the new relationship operation policies
• [Default pundit authorizer keyword args #95] The API of DefaultPunditAuthorizer methods could be changed to use keyword arguments
  • Currently the API change is backwards-incompatible in a way that could be very confusing,
    namely as replace_to_one_relationship has the same amount of parameters but are very
    different than what there was before
  • Keyword arguments are supported ever since Ruby 2.0 so we can use them
• [Handling relationship policy checking in replace_fields #51] Look into the API of DefaultPunditAuthorizer#replace_fields and figure out if it could be implemented similarly to Authorize relationship actions with custom policy methods #40 did
  • The replace operation could even call the new replace/remove relationship authorization methods
  • If this wouldn't be done, we might need to bump to v2.0.0 after implementing as it would be a major breaking change in the API... so better look into it sooner than later
• [Authorize related records on #create_resource #60] Authorize relationships when creating a new resource
• [PR / Help wanted] Document a design pattern for specifying relationship operations logic only once
  • API proposal for authorizing relationships #30 (comment) is a good first start
  • EDIT on 2019-01-22: After a lack of contributions, this was postponed to a future time.
• [Make compatible with jsonapi-resources 0.9 #52] Fix compatibility with v0.9.0 of jsonapi-resources Not compatible with v0.9.0 of jsonapi-resources #36
• [Authorize replacing of a polymorphic has-one relationship #75] Figure out what to do with the replace_polymorphic_to_one_relationship
  • This case that was found in Make compatible with jsonapi-resources 0.9 #52 (comment)
• [add rails 5.0 5.1 5.2 to ci builds #98] Test with Ruby 2.3
• [add rails 5.0 5.1 5.2 to ci builds #98] Test with rails 4.2, 5.0, 5.1 and 5.2
• Release an alpha of 1.0.0 and gather feedback
• Start using the latest release internally at Venuu
• Release a beta of 1.0.0 and gather feedback

...is there anything I've missed?

This roadmap is intended to be a live documentation that can be changed later as need be.

[valscion]

I just published v1.0.0.alpha1 with JR 0.9 compatibility and finer grained authorization for relationship operations and replace_fields scenario. Feel free to take that for a spin and report back issues you find ☺️

/cc @thibaudgg, you might be interested in using the alpha release if you want to use JR 0.9

[thibaudgg]

@valscion thanks, I'll give v1.0.0.alpha1 a try. 👍

[valscion]

Released v1.0.0.alpha2 that contained a fix for #62

[hidde-jan]

Are there any thoughts on how (or if) to incorporate cerebris/jsonapi-resources#1006 and cerebris/jsonapi-resources#977?

From JA:R 0.10 onward, the idea is to delegate record fetching to a RecordAccessor.

In the future, the logic in PunditScopedResource might need to be moved into such a class.

[valscion]

Thanks for the links, @hidde-jan! I wasn't aware of those changes but we'll definitely want to keep this library upwards compatible with JR version 0.10.

I'll create an issue to track this case specifically — let's discuss there if people have more input 😄

[valscion]

Just released v1.0.0.alpha3 with fix for has_one and create_resource authorization, see #66 and #65

[valscion]

NOTE TO PEOPLE USING v1.0.0 VERSIONS:

With the addition of new relationship authorization methods, we had accidentally removed the fallback to #update? mechanism on the newly associated records that was part of v0.8.2

This means that the following scenario did not authorize for the UserPolicy#update? as a fallback mechanism anymore.

article_2 = Article.create(id: 'a-2')
user_2 = User.create(id: 'user-2')

PATCH /articles/a-2/relationships/author

{
  "type": "users",
  "id": "user-2"
}

Authorizes like this:

• ArticlePolicy.new(current_user, article_2).replace_author?(user_2)

...and if replace_author? was not defined, it should have called these:

• ArticlePolicy.new(current_user, article_2).update?
• UserPolicy.new(current_user, user_2).update?

...but the latter call was never made. For replace_fields scenario, it goes like this:

PATCH /articles/a-2

{
  "type": "articles",
  "id": "a-2",
  "relationships": {
    "author": {
      "data": {
        "type": "users",
        "id": "user-2"
      }
    }
  }
}

• ArticlePolicy.new(current_user, article_2).update?
• ArticlePolicy.new(current_user, article_2).replace_author?(user_2)

or if replace_author? wasn't defined, it should've called these:

• ArticlePolicy.new(current_user, article_2).update?
• UserPolicy.new(current_user, user_2).update?

...but the UserPolicy#update? call was never made.

I am fixing this regression case in #70

EDIT: Regression fix released in v1.0.0.alpha5

[valscion]

v1.0.0.alpha6 is released! See release notes for more details: https://github.com/venuu/jsonapi-authorization/releases/tag/v1.0.0.alpha6