Repository navigation
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's my review of the diff:
Summary
The change adds an
is_portal=Truefilter toget_applications(). It looks defensive and is likely correct, but a few things are worth verifying.Potential Issues
Consistency between methods:
get_applications()now filters onis_portal=True, butis_accessible_application(application_id)(the method right below) may not apply the same filter. Ifis_accessible_applicationusesget_applications()internally, fine — but if it queriesApplicationdirectly or checks onlyis_publish, you'll have an inconsistency where an app is "accessible" per one method but absent from the list returned by the other. Worth confirming.Index / performance: Adding
is_portalto theWHEREclause means the query now filters on three columns (id__in,is_portal,is_publish). Make sure there is a suitable composite index, e.g.(is_portal, is_publish, name)or(is_publish, is_portal). Otherwise this can degrade on large tables — especially combined with.order_by("name"), which may not be able to use an index once the filter set changes.Semantic change: Any caller relying on
get_applications()returning all published apps (not just portal ones) will silently lose results. Grep for callers and confirm they expect portal-only behavior.QuerySet construction:
QuerySet(Application)(as opposed toApplication.objects) is unusual. If this is a custom wrapper, fine — but verify it doesn't bypass default managers or soft-delete filters. Also double-check thatQuerySet(Application).filter(...)doesn't re-evaluate per call; cachingget_application_ids()result locally would avoid computing IDs twice if reused.N+1 risk: If downstream code accesses related attributes on each
Application, consider.select_related(...)/.prefetch_related(...)here.Minor Optimizations
self.get_application_ids()in a local variable (if it hits the DB) to avoid duplicate work if called elsewhere in the same request._portal_published_qs()) soget_applications()andis_accessible_application()stay in sync.Verdict
No syntax/logic bug in the diff itself. The main risks are (a) behavioral divergence with
is_accessible_application, (b) missing composite index for the new filter combination, and (c) hidden callers expecting non-portal apps.