feat: add data sharing to sharing dialog [LIBS-677] #1629
Conversation
|
🚀 Deployed on https://pr-1629--dhis2-ui.netlify.app |
| } | ||
|
|
||
| .select-wrapper { | ||
| flex: 1; | ||
| } | ||
| .leftWrapperData { |
There was a problem hiding this comment.
minor: I guess the names of the classes can also be "logical" (start rather than left etc..)
| `}</style> | ||
| </> | ||
| ) | ||
| } | ||
|
|
||
| AccessAdd.propTypes = { | ||
| onAdd: PropTypes.func.isRequired, | ||
| dataSharing: PropTypes.bool, |
There was a problem hiding this comment.
types also need updating?
There was a problem hiding this comment.
Thank you for the reminder! I've cleaned up the type definition, which also includes some fixes:
- I've added in dataSharing on the component level
- I've updated the users/groups to be arrays of SharingObject
- I've replaced the import of
ModalOnCloseEventHandlerwith the definition from ui/modal types (the type was exported from modal types and only consumed in this type file, but was imported incorrectly)
I spoke with @Birkbjo and we decided that for the access type, we would just use the new type definition {metadata: 'ACCESS_NONE' | 'VIEW_ONLY' | 'VIEW_AND_EDIT'; data: 'ACCESS_NONE' | 'VIEW_ONLY' | 'VIEW_AND_EDIT'} rather than also advertise the existence of the backwards compatible type. (Note: that none of our DHIS2 repos appear to currently be using the initialSharingSettings prop when consuming component)
| } | ||
| ) | ||
|
|
||
| // dhis2-uicore-singleselect-prefix |
# [9.14.0](v9.13.0...v9.14.0) (2024-11-13) ### Features * add data sharing to sharing dialog [LIBS-677] ([#1629](#1629)) ([7e15c7f](7e15c7f))
# [10.0.0-alpha.8](v10.0.0-alpha.7...v10.0.0-alpha.8) (2024-11-21) ### Bug Fixes * peer dependency issue with npm publish ([#1628](#1628)) ([1319654](1319654)) * update calendar tests for react 18 ([98831a7](98831a7)) * update testing-library for selector-bar ([893024d](893024d)) * **translations:** sync translations from transifex (master) ([d89ce94](d89ce94)) * **translations:** sync translations from transifex (master) ([7f22330](7f22330)) ### Features * add data sharing to sharing dialog [LIBS-677] ([#1629](#1629)) ([7e15c7f](7e15c7f)) * make input field clearable and add prefix icon ([#1619](#1619)) ([7f87fb4](7f87fb4)) * update react peer dependency to react@18 ([#1624](#1624)) ([5d3c2a4](5d3c2a4))
Implements LIBS-677
Description
Adds data sharing to sharing dialog:
If you do not have
dataSharing: true, the sharing dialog continues to behave as before (there's probably some slight css differences from previous, but nothing of particular note):Some notes:
dataSharing: trueon component. By default, this is false, and hence if not provided, you will just see a sharing dialog for metadata. @cooper-joe and I discussed whether we should try to either automatically enable data sharing for certain object types or automatically prevent if for certain object types, and we thought that that would create a fair amount of work to check/maintain lists of relevant objects for data sharing. In the end, we decided to just let consumers decide if they should enable data sharing.initialSharingSettingson the component to allow the passing ofACCESS_NONE,VIEW_ONLY, orVIEW_AND_EDIT(rather than the object format of {data:ACCESS_NONE|VIEW_ONLY|VIEW_AND_EDIT, metadata:ACCESS_NONE|VIEW_ONLY|VIEW_AND_EDIT}. If you provide access details as a string, this is assumed to apply for metadata only, e.g. passingaccess: "VIEW_ONLY"will be converted toaccess: {data: "NO_ACCESS", metadata: "VIEW_ONLY"}Known issues
username. This is not, however, being provided by the api/sharing response, and making a request just to retrieve username seems inefficient. Talked this over with Joe and we decided that we would use user.id for now and request that username be added to api/sharing response for users array.Checklist
Note: I've overwritten the automatically generated API docs as they were not properly generating a description for the
initialSharingSettingsobject. (This might be counterproductive, as I suppose it will be overwritten)For tests, I've added a number of e2e tests in cypress. The existing tests cover the component in metadata only mode, so I've added a new feature file that covers the add/edit/remove functionality with data sharing. The tests could have more iterations in the scenarios, but I didn't think it was particularly useful to add more (given the comparative slowness of the cypress tests + lack of extra value of the additional scenarios)