jcoffey-dev is traveling from Thursday 1 October through Sunday 4 October. Issues and pull requests are welcome, and will get an answer after that. Thanks for your patience.
Found in prod testing: a delegate opening a locked account in the webmail got its mail, but its calendar, contacts and files didn't come through.
On the server side, the delegate's access token listed the locked account only for kinds of data it already held grants on. An account with no files (or no calendar) was therefore refused to the delegate outright with "You do not have access to account".
Now the token lists every current delegation's locked account for mail, calendars, contacts and files, so a kind with nothing in it reads as empty. Per-item access is unchanged: what a delegate sees or changes is still each container's ACL grant.
The webmail half (the calendar, contacts and files views following the account in view) is a separate PR in ihasmail-inbuxa.
Test: system::account_lock checks that FileNode/query, Calendar/get and AddressBook/get on the locked account answer the delegate, including for an owner with no files. It passes on RocksDB.
Found in prod testing: a delegate opening a locked account in the webmail got its mail, but its calendar, contacts and files didn't come through.
On the server side, the delegate's access token listed the locked account only for kinds of data it already held grants on. An account with no files (or no calendar) was therefore refused to the delegate outright with "You do not have access to account".
Now the token lists every current delegation's locked account for mail, calendars, contacts and files, so a kind with nothing in it reads as empty. Per-item access is unchanged: what a delegate sees or changes is still each container's ACL grant.
The webmail half (the calendar, contacts and files views following the account in view) is a separate PR in ihasmail-inbuxa.
Test: `system::account_lock` checks that FileNode/query, Calendar/get and AddressBook/get on the locked account answer the delegate, including for an owner with no files. It passes on RocksDB.
A delegate's token listed the locked account only for kinds of data it
held grants on, so one with no files (or no calendar) was refused to the
delegate outright: "You do not have access to account". The token now
lists the locked account for mail, calendars, contacts and files alike,
so an empty kind reads as empty. What the delegate may see or change is
still each container's grant (AL-7).
A shared account refuses top-level folders, so an organize or full
delegate couldn't add anything to a locked account with no folders. A
delegate who may write now can, as the owner could; the reconcile after
the create grants it the new folder. Read delegates still can't (AL-6,
AL-7).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found in prod testing: a delegate opening a locked account in the webmail got its mail, but its calendar, contacts and files didn't come through.
On the server side, the delegate's access token listed the locked account only for kinds of data it already held grants on. An account with no files (or no calendar) was therefore refused to the delegate outright with "You do not have access to account".
Now the token lists every current delegation's locked account for mail, calendars, contacts and files, so a kind with nothing in it reads as empty. Per-item access is unchanged: what a delegate sees or changes is still each container's ACL grant.
The webmail half (the calendar, contacts and files views following the account in view) is a separate PR in ihasmail-inbuxa.
Test:
system::account_lockchecks that FileNode/query, Calendar/get and AddressBook/get on the locked account answer the delegate, including for an owner with no files. It passes on RocksDB.