set_project_access() logic

[chris9404]

Hi,

Some comments regarding the set_project_access logic:

1. Giving write_access to a list of users does not include read_access. So if I only give write_access to users (as I did, and thought I broke something) the users appear on the Mergin project as having access, but they can't see their projects on Input. On the Mergin site you choose either reader/writer/owner and I thought the same logic would be valid for this function, i.e. choose one; the owner includes writer and reader, and writer includes reader.
2. Once I, the Owner of the project, give a list of users permission, I lose my own Read and Write permissions, although I stay the Owner. This is a much less significant comment, as the error that appears when running the work-package creation script is quite clear and I realized what the problem was, but if it's a relatively simple change then I would appreciate it.

Both issues have relatively simple fixes user side, but implementing fixes could help avoid problems for future users.

[wonder-sk]

hi @chris9404 thanks for the comment. Agreed with both points that it is surprising behavior. The set_project_access() is relatively a low-level API, where it is somehow expected that the client does the requests correctly, yet all the details are not properly documented. I am hoping that we will address this when we implement #98 which will also add some higher-level functions to MerginClient, e.g.:

• add_users_to_project(['user1', ...], role='writer') ... would ensure that also 'reader' role gets assigned and existing users (e.g. owner) are untouched
• remove_users_from_project(['user1', ...])