[bug] cc.write(overwrite=True) affecting permissions

For carto version <=0.6.2 I am seeing the following strange behaviour.

If I overwrite a dataset using cc.write(df,"dataset",overwrite=True) then any share permissions on the updated dataset stop working.

You can test it as follows:

# pipenv install "cartoframes<=0.6.2" jupyter --skip-lock

import cartoframes
from cartoframes import Credentials
import pandas as pd
import requests

#  ---Setup two users one is the dataset owner the second has the dataset shared with it---
privateuser="privateuser"
private_url="https://privateuser.carto.com"
private_api_key="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

publicuser="publicuser"
public_url="https://publicuser.carto.com"
public_api_key="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

cc = cartoframes.CartoContext(base_url=private_url, api_key=private_api_key)

private_dataset = "private_table"
df = cc.read(private_dataset)

updated_df = df
updated_df.value = round(df.value*1000)

# Write and fetch
url = f'{public_url}/api/v2/sql?q=SELECT * FROM "{privateuser}".{private_dataset} LIMIT 10&api_key={public_api_key}'

# Before the write the URL works fine
r = requests.get(url) 
r.status_code == 200

cc.write(updated_df, private_dataset, overwrite = True)

# After the write the URL returns 401 permission denied
r = requests.get(url) 
r.status_code == 401
r.content
# b'{"error":["permission denied for relation private_table"]}'

In the rails app the ACL/Permissions record for the dataset hasn’t changed. So I don’t understand why it would reset the permission when querying via the sql api?

[andy-esch]

Ok, it’s confirmed: if you create an api key for a dataset, then do a cartoframes write operation with overwrite, then that invalidates the api key/table combo.

This is a feature of the Auth API that I wasn’t aware of until now. To prevent this from happening in cartoframes would require a non-trivial refactoring of the code as well. We’re going to put our heads together and figure out a solution and ping back here because the behavior you are expecting is what should be in place.

cc @inigomedina

[oleurud]

I like the idea. We could even move deeper doing truncate the default one and making the DROP + CREATE the “special” case (only for cases when the data structure has changed (user will be responsible of choosen the right option))