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

share-internal / calendar-task-note file attached #9055

Closed
bjarkan opened this issue Apr 2, 2018 · 4 comments
Closed

share-internal / calendar-task-note file attached #9055

bjarkan opened this issue Apr 2, 2018 · 4 comments
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap enhancement feature: files feature: sharing needs info

Comments

@bjarkan
Copy link

bjarkan commented Apr 2, 2018

Not issue, more a request for new functionality.

What if I need to add a file or folder to a task, or a calendar appointment, or any other internal app?

One solution that i think will be valid is a kind-of share for a file. A kind of share that is internal to the same user that created it. So you can copy a link and add it to the note, calendar text, or description in a task, or even in a kanban.

Clicking that "special share link" will open the specified file, folder or whatever it points to. But without exposing that "share" to any other user, just for internal use, allowing to refer a file or folder in the text.

That could be a very tricky way to attach files to task, calendar, notes, kanban or whatever future functionality implemented.

Could be more fashion, if you could manage them as in email app, with attachments... But this approach is less heavy in terms of usability and processing time when a file is claim to be download.

In my opinion it will be so easy to add to the table a new field, even a boolean one, "private" for example, in the table where all the shared links reside. Adding a check in the part that read the link and give the interface if the link is only possible with the same user that created or just anyone.

This change could be very easy to do. But in terms of usability is several orders of magnitude more useful for final user. In the other hand, just checking true/false before giving an interface to download the file will give the user the privacy of sharing only internal with apps, but not exposing the file to malicious GETs to the webserver.

@bjarkan bjarkan changed the title share-internal / calendar-task-note file attached [feature request] share-internal / calendar-task-note file attached Apr 2, 2018
@MorrisJobke
Copy link
Member

cc @nextcloud/designers (for the UX) @juliushaertl (deck app stuff that does this) @karlitschek (for the vision)

@MorrisJobke MorrisJobke added enhancement feature: sharing 0. Needs triage Pending check for reproducibility or if it fits our roadmap feature: files labels Jun 6, 2018
@MorrisJobke MorrisJobke changed the title [feature request] share-internal / calendar-task-note file attached share-internal / calendar-task-note file attached Jun 6, 2018
@nextcloud-bot nextcloud-bot added the stale Ticket or PR with no recent activity label Jul 7, 2018
@jancborchardt
Copy link
Member

Yes, the Deck app does exactly this already. Other apps can simply utilize a filepicker to attach files to other elements like Contacts, Calendar events etc.

Of course as always, there needs to be the need for this (for Deck there was, so it’s in there) and someone who implements it. :) So any contribution is welcome.

@skjnldsv
Copy link
Member

@juliushaertl so, this is similar to collections, right?

@juliusknorr
Copy link
Member

Yes, @bjarkan you might want to check out Nextcloud projects https://nextcloud.com/blog/nextcloud-16-allows-you-to-link-resources-to-keep-track-of-your-projects/

Calendars are currently not supported but afaik @georgehrke was already looking into that. 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap enhancement feature: files feature: sharing needs info
Projects
None yet
Development

No branches or pull requests

6 participants