Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use list of own attachment files in AttachmentResolver #3974

Closed
mejo- opened this issue Mar 22, 2023 · 0 comments · Fixed by #5042
Closed

Use list of own attachment files in AttachmentResolver #3974

mejo- opened this issue Mar 22, 2023 · 0 comments · Fixed by #5042
Assignees
Labels

Comments

@mejo-
Copy link
Member

mejo- commented Mar 22, 2023

Summary

Currently AttachmentResolver.js misses important information about attachments, which leads to a lot of complexity in resolving attachments.

To make this more straight-forward (at least for "own attachment files" - a.k.a. the ones living in .attachments.<fileId>), we could do the following:

  • Add an API endpoint to get the list of files in the attachment folder along with their metadata (fileId, fileName, size, mimetype, timestamp, hasPreview, maybe even davUrl already). This endpoint would need to allow authentication both via Text session and via logged in user.
  • Always request this list when loading a Text document in Editor.vue (asynchronously, non-blocking).
  • When resolving attachments in AttachmentResolver.js, look up the attachment in the retained list and use all available information from there.

Implementation details

  • The list could either be stored in vuex store or the promise of the request could be passed to AttachmentResolver constructor.
  • When a new attachment is uploaded in Text, we either have to add it to the list in frontend, or retrieve an updated list as response and replace the list. (That might be arguments to maintain the list in vuex store 🤔)

Advantages

  • For "own attachments" we could return better first candidates from AttachmentResolver.
    • Non-image attachments would get a first candidate with type: media, resulting in fewer requests during <img> loads.
    • No extra requests required for getting metadata for attachments.
  • We would have the fileId of attachments available.

Disadvantages

  • One more backend request (at least for documents without attachments).

@juliushaertl @julien-nc @max-nextcloud for feedback.

@github-project-automation github-project-automation bot moved this to 🧭 Planning evaluation (don't pick) in 📝 Office team Jul 11, 2023
@mejo- mejo- moved this from 🧭 Planning evaluation (don't pick) to 📄 To do (~10 entries) in 📝 Office team Jul 11, 2023
@mejo- mejo- self-assigned this Oct 25, 2023
@mejo- mejo- moved this from 📄 To do (~10 entries) to 🏗️ In progress in 📝 Office team Oct 26, 2023
@mejo- mejo- mentioned this issue Nov 27, 2023
49 tasks
@github-project-automation github-project-automation bot moved this from 🏗️ In progress to ☑️ Done in 📝 Office team Nov 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

1 participant