id,summary,reporter,owner,description,type,status,priority,milestone,component,resolution,keywords,cc,rd_points,sprint,story_priority 11753,read-write in clients,jburel,,"Overarching ticket for tasks required to enable read-write group support in the client. The read-write state (`rwrw--`) is available as a server option but has been kept out of the clients due to the complexity that it adds. In order to make the flag available across the board, we will need to: 1. review the existing integration tests in Java & Python * include specific classes for: images, containers, rendering, annotations, ... * effort should be made to reduce variability in class/method naming, etc. 2. likely write new integration tests to cover `rwrw--` 3. ensure coverage of client-side API methods (`canEdit()`, `canAnnotate()`, ...) for the various user types (data-owner, group-member, group-owner, admin) 4. evaluate needed changes to client-side API methods (client devs: Will/J-m/...) * Do we need `canInsert()`? 5. update the spreadsheet(s) that are being maintained (client devs + Petr/Balaji) * possibly simplifying them * possibly generating integration tests from them * possibly converting to a more maintainable format) * 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. A primary goal of the above would be to have the following representations/implementations of permissions all coincide **minimally** for `rwrw--`: * client (i.e. user) functions (GUI) * client gateway methods * client-side API methods (canEdit, etc) * low-level permissions object (e.g. `rwrw--`) * server-implementation * integration tests * and finally the ""Spreadsheets"" (i.e. permissions documentation) If possible, no client/server breaking changes should be made so that the work could be backported to the 5.0 series if desired.",story,new,critical,5.1.0,Client,,,ux@… jamoore sbesson java@… python@…,,,