hey, i was going through projects/services/subscriptions.py and noticed something that might lead to inconsistent subscription state over time
found that in follow_all_project_questions and related flows, we create PostSubscription entries based on the posts a user currently has access to
posts = (
Post.objects.filter_projects(project)
.filter_permission(user=user)
.filter_questions()
)
but if a user later loses access to the project, their existing PostSubscription records are not cleaned up and still remain in the db
i see that in some places (like notifications) we re-check permissions
subscriptions.filter(
user__in=post.default_project.get_users_for_permission(
ObjectPermission.VIEWER
)
)
so it looks like the system relies on checking permissions at read/notification time rather than ensuring that the underlying data (subscriptions) stays consistent with access control
am curious to know whether this was intentional or was it more of a system design oversight where subscriptions should be cleaned up when access changes?
hey, i was going through
projects/services/subscriptions.pyand noticed something that might lead to inconsistent subscription state over timefound that in
follow_all_project_questionsand related flows, we createPostSubscriptionentries based on the posts a user currently has access tobut if a user later loses access to the project, their existing
PostSubscriptionrecords are not cleaned up and still remain in the dbi see that in some places (like notifications) we re-check permissions
so it looks like the system relies on checking permissions at read/notification time rather than ensuring that the underlying data (subscriptions) stays consistent with access control
am curious to know whether this was intentional or was it more of a system design oversight where subscriptions should be cleaned up when access changes?