Add files (stored in Drive) that are not owned by you
It could be nice to be able to add files from Drive into AODocs that are not owned by you. Currently for end users, if they want to store in AODocs a file that is not owned by them, they either have to make a copy of it or get the original owner to transfer ownership to them.
Comments
I would also need this functionality but the owner of the file will have to approve that. Otherwise it's too dangerous ! One of your file can be move to AODocs without your permission
Good point, Cecilia, and this would provide an approval step out of respect to the owner.
We've migrated to AODocs and afterwards are setting up some Document Management Systems. Even when the files and the DMS are managed by the same storage account, we're not able to add these files into the DMS (because they are already added to AODocs).
So we are facing the issue that once added to AODocs we can't upload files anymore to a new DMS. Like Cecilia says with approvement of for example at least one admin.
Hello,
@Julie, regarding your last comment, it seems to be closer to this feature request from Samantha: https://support.aodocs.com/hc/en-us/community/posts/115009641126-Remove-an-attachment-Export-an-attachment
@Jeremy, as a reminder, the only library that allows files not owned by you to be imported into AODocs is Team Folder library. We haven't planned so far to add this possibility to other library types.
Let us know what you think.
Have a good day.
Ok, this has become a very very big problem for us. Aside from copy/download, is there any way around this?
On several projects we have multiple people/tools creating files in a Shared Google Folder, and then importing to an AODocs Lib to use the final workflow approval. Don't ask why, don't get defensive and rebuff. That is the way it is.
AND we cannot even import from an AODocs Team Folder? Which would be a great safe workaround.
I understand it is a basic safeguard and fundamental view of the world for the tool. BUT IN OUR CASE, we want that restriction removed! Seriously. On a per-library basis would be nice, or even per-user if you can't see past this restrictive mentality. Or just from an AODocs Team Folder!
This is also a huge obstacle in our environment. Often our documents go through a variety of draft phases before they get uploaded to a DMS library for workflow etc.
Often there are several admins involved so ownership varies and if someone is out of the office, they cannot change ownership. Making a copy creates confusion and undoes the whole point of Drive which is a "single source of truth".
Our environment is open and collaborative so we are not concerned about "stealing" or losing access. We consider everyone a professional and would solve any issues by examining our process and having discussions.
I think the approval is what is needed. Currently, it pops up an email asking the owner to transfer it. It would be better if all they had to do was click an "approve" button, and then it would move automatically.
This is a barrier in our setup as well.
One more thought on this...To be completely honest, while I am not sure I personally like this idea, what my users really want, is the option of a folder security type where AODocs does not become the owner of the document - but document ownership remains unchanged.
Here is our use case. We are using this for grant development. During the initial pre-award phase, there are documents that are referenced by the grant team, that are used for a wider purpose than just this grant development. Once the grant moves out of the pre-award into post-award, the document is no longer needed. Hence, the grant team do not consider themselves the "custodian" of these one-off documents. Also, the grant team does not wish to grant access to the grant folder to everyone who is using the one-off document.
Our solution thus far has been to keep this stage out of AODocs, in just regular Google folders, and then to bring the documents in, in a later stage. In other instances, we just store the URL of the document, rather than the document itself.
Please sign in to leave a comment.