[nicotsx]

Summary by CodeRabbit

• Bug Fixes
  • Corrected access-rule decisions when both allow and block lists are configured: users matching the allow list are allowed unless they also match the block list, and matching blocked users remain denied.
  • Users matching neither list are denied. When the allow list is empty, a configured block list allows users who do not match it; with neither list configured, the rule abstains.

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: tinyauthapp/tinyauth
• Branch: fix/policy-evaluation
• File: .coderabbit.yaml
• Commit: 1e02af0
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 6ed87e4b-ff3c-41de-9ea1-a64f299afeea

Commits

Reviewing files that changed from the base of the PR and between c3b5c04 and 1e02af0.

Files selected for processing: 2

• internal/service/access_controls_rules.go
• internal/service/access_controls_rules_test.go

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 5 remain after this review.

Walkthrough

UserAllowedRule.Evaluate now checks the allow list when a user does not match the block list. When the allow list is empty, it allows if a block list is configured; otherwise, it abstains. Tests cover three combinations of username matches.

Changes: Access rule evaluation

Layer / File(s)	Summary
Block-list and allow-list evaluation internal/service/access_controls_rules.go, internal/service/access_controls_rules_test.go	The rule continues to the allow-list check after a block-list non-match. With an empty allow list, it allows when a block list is configured and otherwise abstains. Tests cover users matching the allow list only, both lists, or neither list.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: steveiliop56

Merge Risk: Minimal · up to 1e02a

The policy evaluation change matches the documented behavior and added test cases, with no material merge risk identified.

Pre-merge checks: 4 · 1

Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks: 4 passed

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title identifies the policy evaluation change. It is broad, but it accurately describes the main purpose of the pull request.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 1 functions across 2 files.

Resolution

Write docstrings for the functions missing them to satisfy the coverage threshold.

Finishing Touches: 💡 1

📝 Generate docstrings: 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[steveiliop56]

This is intended behavior.

users.allow and users.block are intended to be alternative modes:

• users.allow enables allow-list mode.
• users.block enables block-list mode.

They are not meant to be used together. Allowing both would make the resulting policy ambiguous and would likely be more of a foot-gun than useful behavior.