nextcloud
Applications / Contexts
Lets create contexts where we can put different resources together to act like an small app (smapp 🙃). Resources can be views, tables, a description (rich text with all the smart picker magic) and maybe other "related resources" from nextcloud, chat room, files directory, ...
Subtasks
- [x] #812
- [x] https://github.com/nextcloud/tables/pull/861
- [x] #807
- [x] #864
- [x] #908
- [x] #863
- [x] #896
- [x] #895
- [ ] #897
- [x] #898
Follow up
- [ ] #933
- [ ] #934
- [ ] #935
Summary
- The user facing naming would be "Application" but code wise we use Context to avoid confusion with Nextcloud apps of all sorts
This is what we discussed in Berlin in person within the contributor week:
Unsorted further related input from the feature planning meeting for future discussions:
- Look more from the user perspetive than tables developer (what to prioritize in the UI, how to present tables/views/contexts to the user)
- For most users receiving shared views might be the most important
- Possibly group them by their parent table/context
- Wording of views
- Possibly separate table design and usage more
- Reusable definitions (table schema + views), import/export, sharable, maybe through the app store on the long term
@datenangebot Can you provide a summary of what was discussed in Berlin and what the MVP would look like and need in terms of implementation as discussed?
Can you provide a summary of what was discussed in Berlin and what the MVP would look like and need in terms of implementation as discussed?
I updated the initial post here with some mockups. @jancborchardt @nimishavijay did I got that right or do you have something to add?
From the discussion with @datenangebot
- Q1: Contexts will be owned by a user in
- Out of scope but planned for the future: Make a group the owner
- Permission management
- Q2: Each user with manage permission on a resource can add it to a context they create
- The resource will show linked contexts
- When the user looses manage permission, the context linking will still persist, listing them will give the resource owner control over who has access to data, but the manage permission is considered trusted to extend the base resource permissions to others through contexts
- A context can be shared to users/groups
- There is a set of default permissions that are applied to all share recipients for now
- Out of scope: In the future we may extend this by addition individual acl/permissions per user/group share and resource
- Sharing through multiple groups shall be merged to one receiving share
- Q2: Each user with manage permission on a resource can add it to a context they create
Frontend
- Add separate section with "Applications" which is the user facing naming for "Contexts" to the sidebar
- Each context can have a material design icon
- see if a nice picker is available, hand picked list otherwise as first step for the app menu icons
Implementation
- Frontend: Refactor table component to be usable in multiple instances at the same time
- Backend: Implement database layout, API endpoints to create context
- Frontend: Implement sidebar entries, listing, new context button (partly requires 2 but could be started already)
- Frontend: Implement modal for creating/editing context (partly requires 2 but could be started already)
- Frontend: Implement vue routes to handle contexts (requires 1, requires 2 but could be started already)
- Backend: Expose contexts as app menu entries (partly requires 2)
@jancborchardt @marcoambrosini Brought up that the name applications is quite confusing as it conflicts with apps still
Marco also brought up that it probably would make sense to reconsider how we implement this within tables or separately considering that there is quite some overlap with the interactive widgets / projects feature.
A quick idea could be to just allow users building an "application" within a collective page by adding tables interactive widgets and then add this collective page to the app navigation. That way contexts would not be limited to tables but could also be used to combine other resources like calendars, deck lists in a "no-code" app. That also kind of matches the vision that Florian had shared with me in some mockup
@juliushaertl @marcoambrosini that would increase complexity and time to just get an app by a lot though. Let's not overengineer the first steps. :)
The comparison here is https://www.glideapps.com – a nice looking "app-like" view starting from even just 1 table. Which also includes showing these entries e.g. as a calendar view, since one column might be a date.
When we achieved that we can think about future stuff. :)
Yes, as also briefly discussed with @datenangebot We have a limited scope for this feature now with 29 and can iterate over integrating this further later on. Let me mark those comments as off-topic, we can consider further improvements in later rounds.
Results of a few aspects that were discussed in today's call between @datenangebot, @juliushaertl and me:
- Permissions/Access: defined more scenarios
- since resources will stay available in Contexts even when the owner looses management permissions on tables, it must be transparent to the table owner in which Contexts their data is being used. In the sidebar information on a table it could be shown below the list of Views.
- since Contexts are decoupled from tables permissions upon their embedding, tables cannot be withdrawn from Contexts, even by their table owners
- this may change in the future with a holistic ACL concept.
- Transparency and Acceptance User must have confidence and oversight
- it must be clear to the users that handing out permissions on tables, they hand out the permission that those data may be shared, e.g. with Contexts. The consequences of sharing or giving permissions must be know so users are not experiencing surprise and may loose confidence in Nextcloud. Therefore, it must be clear already in the UI, not just the documentation.
- User life cycle: behaviour on state changes
- when deleting a user, all owned contexts are deleted, too. This is consistent with general Nextcloud behaviour, and existing Table behaviour on tables (and thus view).
- when a user is disabled, everything stays intact, as is currently the case with tables and views
- Transfer Ownership: to address user fluctuation, handing over Contexts will be possible
- owner level: a user may transfer a Context to a different Context member. Ownership transfer already exists for tables, though it is not released yet.
- admin level: through occ an admin may transfer a Context to another user. In this case it is not necessarily a Context member. (This may change in future).
Backend: Implement database layout, API endpoints to create context
DB draft at https://github.com/nextcloud/tables/issues/812