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

Feature request: Ability to attach (add) an existing attachment from another page in a group #381

Open
fabacab opened this issue Jan 31, 2016 · 2 comments

Comments

@fabacab
Copy link

fabacab commented Jan 31, 2016

Sometimes I find myself wanting to move an attachment from one page to another. This usually occurs when the attachment (usually a work file such as an image or a PDF) is attached to a page by someone else, but during re-organization, I want to attach it to a different page.

Currently, I am forced to re-upload a new copy of the attached file; this isn't a huge burden but it seems sub-optimal. It also has the potential to cause confusion due to the inherent fragmentation, unless I also remove the attachment from the original page.

This is also distinct from the "File" option available in Crabgrass. I tend to see "File" pages as working documents that my group and I create ourselves, things we iterate over and over, want to keep versions of, and so on. Attachments, on the other hand, are often things we are given from individuals outside our own group, like reports, deliverables, and so on. These are things we should not change ourselves.

It would be great if Crabgrass allowed me to attach a single document to more than one Wiki page, for instance, or at least to be able to re-assign an uploaded attachment asset from one page to another.

@azul
Copy link
Contributor

azul commented Feb 2, 2016

We used to have something similar for gallery pages. You could have the same image displayed on multiple galleries. Turns out it's a mess for permissions:
What if an asset is shared from a page with one set of permissions to a page with a different set of permissions? Well it should probably show up on both pages for all users that have access to each of the pages. Not so hard, right?
Well... fetching the page and fetching the thumbnail or the attachment itself are two distinct requests. So for the second request we need to check if the asset is attached to any page the user has access to. Determining the access to a single page is quite complex all by itself. You can have access because the page has been shared with a committee of a network one of your groups is in.
So we decided that pages determine access permissions. Everything that is access restricted can only be on a single page.

So I am open to copying or moving assets from one page to another. However copying would effectively create a new asset with the same content rather than sharing the same asset between the pages. I'd rather waste disc space than deal with increasing the complexity of our permission system.

@fabacab
Copy link
Author

fabacab commented Feb 2, 2016

So I am open to copying or moving assets from one page to another. However copying would effectively create a new asset with the same content rather than sharing the same asset between the pages. I'd rather waste disc space than deal with increasing the complexity of our permission system.

That makes sense to me.

The simplest use case for this is just wiki gardening: I want to move Asset 1 attached from Page A to Page B where both Page A and Page B are within the same group. Currently, doing this is a somewhat involved process:

  1. Locate Asset 1 on Page A.
  2. Download/copy Asset 1.
  3. Go to Page B.
  4. Upload local copy of Asset 1 to Page B, creating Asset 2.
  5. Return to Page A.
  6. Delete Asset 1 from Page A.

If the only thing that happens is a convenience button to perform these steps for me, we can call it "Move asset to another page" for instance, I would be happy. :) In this case, nothing about the logic to determine access permissions for the asset would need to change.

Does that sound feasible?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants