Applications / Contexts

[datenangebot]

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

• RFC: DB Structure for Contexts #812
• Contexts API #861
• Applications: Enable multiple tables instances at the same time #807
• Applications: Implement route to show a context #864
• Applications: Implement fetching contexts and listing them in the navigation #908
• Applications: Expose in app menu #863
• Applications: Create/edit modal #896
• Applications: Ship icons and icon list for frontend/backend #895
• Applications: Sharing #897
• Applications: Transfer ownership #898

Follow up

• Applications: Backend/frontend - Indicate active context in the navigation #933
• Applications: Frontend - Allow to change order of the context resources #934
• Applications: Design review tasks #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:

[juliushaertl]

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

[juliushaertl]

@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?

[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?

I updated the initial post here with some mockups.
@jancborchardt @nimishavijay did I got that right or do you have something to add?

[juliushaertl]

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

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

1. Frontend: Refactor table component to be usable in multiple instances at the same time
2. Backend: Implement database layout, API endpoints to create context
3. Frontend: Implement sidebar entries, listing, new context button (partly requires 2 but could be started already)
4. Frontend: Implement modal for creating/editing context (partly requires 2 but could be started already)
5. Frontend: Implement vue routes to handle contexts (requires 1, requires 2 but could be started already)
6. Backend: Expose contexts as app menu entries (partly requires 2)

[blizzz]

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).

[blizzz]

Backend: Implement database layout, API endpoints to create context

DB draft at #812

[juliushaertl]

Closing, we will track follow ups in separate issues.