Support foreign key lookup on API requests #535

New Issue

mpeltriaux · 2026-05-10T06:49:20Z

mpeltriaux commented

2026-05-10 06:49:20 +00:00

Status quo

Until now, further requests e.g. to update an API transmitted entry need to use the internal id of an entry. This id has been returned to the client on the initial creation of the entry before.

Improvement

However, due to current requesting of LBM, we should implement some logic, that does not only work on the internal ids but also supports foreign ids of some other source system. This way, the client would be able to use these foreign ids to perform actions on an entry.

Furthermore we should take into account that foreign ids could change over time. (Of course this should not happen, but doesn't stop reality from becoming true). So multiple different foreign ids should point to the same internal id.

# Status quo Until now, further requests e.g. to update an API transmitted entry need to use the internal id of an entry. This id has been returned to the client on the initial creation of the entry before. # Improvement However, due to current requesting of LBM, we should implement some logic, that does not only work on the internal ids but also supports foreign ids of some other source system. This way, the client would be able to use these foreign ids to perform actions on an entry. Furthermore we should take into account that foreign ids could change over time. (Of course this should not happen, but doesn't stop reality from becoming true). So multiple different foreign ids should point to the same internal id.

mpeltriaux added the enhancement label 2026-05-10 06:49:20 +00:00

mpeltriaux self-assigned this 2026-05-10 06:49:20 +00:00

mpeltriaux referenced this issue

2026-05-10 10:10:47 +00:00

535_Support_foreign_key_lookup_on_API_requests #536

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: IT-Naturschutz/konova#535