Skip to content

Add users transfer_resources to hand resources to another user - #141

Open
christianbraun wants to merge 1 commit into
GeoNodeUserGroup-DE:mainfrom
christianbraun:feature/transfer-resources
Open

Add users transfer_resources to hand resources to another user#141
christianbraun wants to merge 1 commit into
GeoNodeUserGroup-DE:mainfrom
christianbraun:feature/transfer-resources

Conversation

@christianbraun

Copy link
Copy Markdown

Adds the one thing that was missing to move a resource to a different owner from the command line:

geonodectl users transfer_resources 3 --new_owner 7
geonodectl users transfer_resources 3 --new_owner 7 --resources 11 12

POST /api/v2/users/{pk}/transfer_resources exists in two shapes. GeoNode 5 takes newOwner, currentOwner and an optional list of resource ids; GeoNode 4.4 takes a single owner and always moves every resource the user owns. The modern payload goes out first, and the legacy one is only tried after GeoNode answers that it did not understand it. A subset is never retried that way - the 4.4 endpoint would move everything rather than the resources that were asked for, so that case raises instead.

resources is always sent, empty for a whole-account transfer. GeoNode 5 raises a TypeError on a JSON body that leaves the key out entirely (GeoNode/geonode#14473), and an empty list walks around it.

Four unit tests in tests/test_users.py, mocking http_post in the same style as the existing handler tests. unittest discover is green (48 tests), black and flake8 clean, mypy -p src.geonoderest --check-untyped-defs --disable-error-code=import-untyped reports only the pre-existing raise NotImplemented in geonodectl.py.

Not tested against a live GeoNode yet - review welcome on whether the version fallback is the shape you want, or whether you would rather gate it on a configured API version.

    geonodectl users transfer_resources 3 --new_owner 7
    geonodectl users transfer_resources 3 --new_owner 7 --resources 11 12

Wraps POST /api/v2/users/{pk}/transfer_resources, which exists in two shapes.
GeoNode 5 takes newOwner, currentOwner and an optional list of resource ids;
GeoNode 4.4 takes a single `owner` and always moves every resource of the user.
The modern payload goes out first and the legacy one is only tried after
GeoNode answers that it did not understand it. A subset is never retried that
way, since the 4.4 endpoint would move everything rather than the resources
that were asked for.

`resources` is always sent, empty for a whole-account transfer: GeoNode 5
raises a TypeError on a JSON body that leaves the key out entirely.
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

Successfully merging this pull request may close these issues.

1 participant