| 4 | | * review the client-side API methods (`canEdit()`, `canAnnotate()`, ...) for the various user types (data-owner, group-member, group-owner, admin) |
| 5 | | * review the existing integration tests in Java & Python |
| 6 | | * likely write new integration tests to cover `rwrw--` |
| 7 | | * update the spreadsheet(s) that are being maintained (possibly simplifying them; possibly generating integration tests from them; possibly converting to a more maintainable format) |
| | 4 | |
| | 5 | 1. review the existing integration tests in Java & Python |
| | 6 | * include specific classes for: images, containers, rendering, annotations, ... |
| | 7 | * effort should be made to reduce variability in class/method naming, etc. |
| | 8 | 2. likely write new integration tests to cover `rwrw--` |
| | 9 | 3. ensure coverage of client-side API methods (`canEdit()`, `canAnnotate()`, ...) for the various user types (data-owner, group-member, group-owner, admin) |
| | 10 | 4. evaluate needed changes to client-side API methods (client devs: Will/J-m/...) |
| | 11 | * Do we need `canInsert()`? |
| | 12 | 5. update the spreadsheet(s) that are being maintained (client devs + Petr/Balaji) |
| | 13 | * possibly simplifying them |
| | 14 | * possibly generating integration tests from them |
| | 15 | * possibly converting to a more maintainable format) |
| | 16 | * If this is out of scope, we may want to start by creating a new format just for `rwrw--` and then extend this backwards to `rwra--` etc. |
| | 17 | |
| | 18 | A primary goal of the above would be to have the following representations/implementations of permissions all coincide **minimally* for `rwrw--`: |
| | 19 | |
| | 20 | * client (i.e. user) functions (GUI) |
| | 21 | * client gateway methods |
| | 22 | * client-side API methods (canEdit, etc) |
| | 23 | * low-level permissions object (e.g. `rwrw--`) |
| | 24 | * server-implementation |
| | 25 | * integration tests |
| | 26 | * and finally the "Spreadsheets" (i.e. permissions documentation) |
