• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

kobotoolbox / kpi / 18598022134
81%
master: 76%

Build:
Build:
LAST BUILD BRANCH: beccagraber/dev-1452-new_action
DEFAULT BRANCH: master
Ran 17 Oct 2025 04:36PM UTC
Jobs 2
Files 876
Run time 2min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

17 Oct 2025 03:55PM UTC coverage: 81.287% (+0.008%) from 81.279%
18598022134

push

github

web-flow
fix(dataCollectors): remove assets from groups if owners lose permission DEV-1150 (#6357)

### 📣 Summary
Ensure data collectors can no longer access projects if the group owner
has lost permission.


### 📖 Description
Data collector group owners can only add an asset to their group if they
have the manage-asset permission. If that permission is removed, the
asset should no longer be assigned to the group and all the associated
data collector enketo links should be removed.

### Notes
The big problem that needed to be solved with this PR was the situation
where, as part of recalculating permissions, we delete all old ones
before possibly adding them back. To make matters even more complicated,
we do this every time we save an asset.

The approach this PR takes is to refactor the recalculating of
permissions to only delete the old permissions that we know we want to
delete, rather than deleting and re-adding the ones we care about,
except in the case where `return_instead_of_creating` is passed to the
recalculation method. In that case, it's the responsibility of the
caller to handle whatever problems may arise from removing the
manage_asset permission. This approach has a few benefits:
1. no new db calls. this actually reduces the number of db calls because
we aren't re-creating the same permissions that already exist
2. no data collector-specific code outside of the data collector app
3. we can enforce the removal of assets at the model level, no matter if
the permission was removed permissions from the DCG owner via the
expected endpoint(s) or a different path

Other approaches considered:
1. Updating the bulk delete endpoint to call `post_remove_perm` for each
permission removed and using that as the signal instead of
ObjectPermission.post_delete. Rejected because it would add at least one
database call to the endpoint (to get all existing permissions so we
knew which ones we were removing) and because it's endpoint-specific and
not future-proof aga... (continued)

7061 of 11107 branches covered (63.57%)

20 of 22 new or added lines in 2 files covered. (90.91%)

1 existing line in 1 file now uncovered.

27276 of 33555 relevant lines covered (81.29%)

1.6 hits per line

New Missed Lines in Diff

Lines Coverage ∆ File
2
94.83
0.27% kpi/mixins/object_permission.py

Uncovered Existing Lines

Lines Coverage ∆ File
1
94.83
0.27% kpi/mixins/object_permission.py
Jobs
ID Job ID Ran Files Coverage
1 18598022134.1 17 Oct 2025 04:36PM UTC 874
78.88
2 18598022134.2 17 Oct 2025 04:38PM UTC 876
81.25
Source Files on build 18598022134
  • Tree
  • List 876
  • Changed 3
  • Source Changed 0
  • Coverage Changed 3
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • a7257525 on github
  • Prev Build on main (#18593384025)
  • Next Build on main (#18606842636)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2025 Coveralls, Inc