Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible breaking change with handling of nil conditions in 3.5.0 #821

Open
CJStadler opened this issue Mar 15, 2023 · 2 comments
Open

Possible breaking change with handling of nil conditions in 3.5.0 #821

CJStadler opened this issue Mar 15, 2023 · 2 comments

Comments

@CJStadler
Copy link

Steps to reproduce

In #653 the handling of nil with has_many relations was changed. Previously a rule like

can :read, Document, authors: { user_id: nil }

caused can? :read, document to be true only if document has an author with user_id: nil. In 3.5.0 this behavior has changed and can? :read, document will also be true if document has no authors.

I'm not sure what the better behavior is, but this seems like a breaking change as applications using earlier versions may have been depending on the previous behavior.

Gist with a test case: https://gist.github.com/CJStadler/2d6e6644a72286c823d71c3b96b92a80

Expected behavior

Upgrading a minor version does not change the behavior of existing rules.

Actual behavior

Upgrading from 3.4.0 to 3.5.0 changed the behavior of existing rules, authorizing users to access resources that they were not previously authorized to access.

System configuration

Rails version:
6.1.7
Ruby version:
2.7.5
CanCanCan version
3.5.0

@coorasse
Copy link
Member

Agree. I guess you could clasrify this by adding an explicit test for this case?

@CJStadler
Copy link
Author

Thanks for taking a look @coorasse! #653 did add tests for the new behavior. A test of the previous behavior would now fail, unless #653 was reverted, so I'm not sure what you are suggesting.

What do you think about updating the changelog to warn that #653 is a breaking change? If you have any other suggestions I'd be happy to contribute a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants