-
Notifications
You must be signed in to change notification settings - Fork 940
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Export of messages from internal message system #3106
Comments
I fail to understand what #3105 has to do with wanting to export messages. I mean we can leave this open but I can't imagine anybody rushing to implement a feature that approximately nobody will use anytime soon. What format would we use anyway? Is there some EU standard for portable private messages that I'm not aware of? |
Well if there was an "export and maybe delete" function, I could export the messages from the internal mail system for archival purposes, and reduce the number of messages down to a level where pagination doesn't matter (say once per year). |
Good evening,
No, there's no such format to my knowledge, but what if this took the approach that's ALMOST already there. We already get an email when a new message arrives. What if me made an export as an .eml message possible? The From: and To:-addresses could be something like "OSM USERNAME" <>, essentially giving it empty addresses that will never work from within an email client, but will display correctly. There already is an engine to convert Markdown into HTML to display it, so this could easily feed an text/html MIME part of the .eml file with the text/plain part being either "you need an HTML-enabled client to view this message" or just use the engine that creates the text/plain part of the message for the email we already get nowadays. I would have created a showcase but it seems there's no API access to messages (apart from the Granted, fantasy might have gone a little wild here, but there would be ways to solve this. Magically finding people who code these otoh will be the obvious issue... |
#4509 might provide the technical foundation to build such a tool (even outside of this repo). |
My proposal would be to use some shell script as shown below: (quick & dirty version, please adjust as needed). #!/bin/bash
export TOKEN="..."
echo "Fetching outbox index"
curl --silent -H "Authorization: Bearer $TOKEN" https://api.openstreetmap.org/api/0.6/user/messages/outbox.json > outbox.json
export OUTBOX_IDS=$(jq '.messages[].id' outbox.json)
echo "Total messages: $(echo "$OUTBOX_IDS" | wc --lines)"
for a in $OUTBOX_IDS
do
echo "Exporting outbox message $a..."
curl --silent -H "Authorization: Bearer $TOKEN" https://api.openstreetmap.org/api/0.6/user/messages/"$a".json > outbox_"$a".json
done
echo "Fetching inbox index"
curl --silent -H "Authorization: Bearer $TOKEN" https://api.openstreetmap.org/api/0.6/user/messages/inbox.json > inbox.json
export INBOX_IDS=$(jq '.messages[].id' inbox.json)
echo "Total messages: $(echo "$INBOX_IDS" | wc --lines)"
for a in $INBOX_IDS
do
echo "Exporting inbox message $a..."
curl --silent -H "Authorization: Bearer $TOKEN" https://api.openstreetmap.org/api/0.6/user/messages/"$a".json > inbox_"$a".json
done In case you only want to export non-deleted messages, or export messages to a specific user, etc., adjust the jq expression as needed.
I'm closing here, since the original requirement is sufficiently covered by the new Messaging API. |
Both from a practical (see #3105) and legal POV (GDPR data portability requirement) there should be a way to export the contents of a users in- and outboxes in some kind of portable format.
@woodpeck do you remember if we added this to the de facto defunct GDPR requirements list?
The text was updated successfully, but these errors were encountered: