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 the old deck attachment system #3239

Closed
TheTiEr opened this issue Aug 7, 2021 · 4 comments
Closed

Use the old deck attachment system #3239

TheTiEr opened this issue Aug 7, 2021 · 4 comments

Comments

@TheTiEr
Copy link

TheTiEr commented Aug 7, 2021

How to use GitHub

  • Please use the 👍 reaction to show that you are affected by the same issue.
  • Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is there a way to use the old attachment system of deck? Until all Bugs and not perfect issues which make our workflow super hard are solved?

@stefan-niedermann
Copy link
Member

stefan-niedermann commented Aug 7, 2021

Is there a way to use the old attachment system of deck?

No.

Until all Bugs and not perfect issues which make our workflow super hard are solved?

What makes you assuming that reverting the implementation of the attachments backend is less complicate or less work than fixing remaining issues? Did you also consider a migration or compatibility strategy for file attachments? How will you tackle the drawbacks of the old system, which did not even allow preview generation? (The last point will force thousands of Android app users to download all attachments completely).

It's a bit hard to understand which issues are showstoppers in which scenarios for you, because you decided to completely ignore the issue template. Some attachment related issues i am aware of like #2877 are indeed strange behavior, but do not match my definition of "bug" (disclaimer: I am not maintainer nor developer of the Deck server app, i am not related to Nextcloud GmbH).

@TheTiEr
Copy link
Author

TheTiEr commented Aug 9, 2021

I thought there was something like a swith to use the old implementation.

To understand the issues with the new Files Attachment implementation i need to illustrate our Workflow to you.
We use the Deck to representate the production state of our workpieces. We need to prepare those parts in our cad systems and generate GCode. This GCode gets attached to the card at the deck. The next employee goes downloads this file and starts the Job at the CNC-Machine.

With the new File attachment implementation one has to click click three times to download the file and it takes some time until the site is loaded. This waiting time is a problem of a fairly old machine but this wasnt a problem using the old attachment system.

Moreover if a file with the same is uploaded to another card it is renamed with a ugly bracket after its name. Maybe there is a way to upload those attached files to the linked folder of the card if it has one? This would solve the issue with the files with the same names.

And the last thing is that every user has now a "Deck" Folder in its home directory. Is there a way to hide it? Or at least add subfolders for each card if there is no linked folder at the card?

@stefan-niedermann
Copy link
Member

I thought there was something like a swith to use the old implementation.

Well, no. Switching between those two attachment systems on the fly is not possible.

With the new File attachment implementation one has to click click three times to download the file and it takes some time until the site is loaded.

Yes, i see. Maybe it is some kind of quick win to put a few more entries directly into the three dots menu of the attachment items? Currently there is only Delete while also Rename and Download would make sense. In my opinion this is also superior to #3232 because one keeps the possibility to reach other actions like Share.

if a file with the same is uploaded to another card it is renamed with a ugly bracket after its name. Maybe there is a way to upload those attached files to the linked folder of the card if it has one?

I also agree here: Currently the Deck folder is flat. Using some hierarchy by card (and / or board) would make it way more scalable. I suggest to create a separate issues as i am not aware of it being requested before.

And the last thing is that every user has now a "Deck" Folder in its home directory. Is there a way to hide it?

If the folder was customizable like in the Notes app, this issue would be solved, right? One could even use a . before the name like .Deck which will make it "hidden". I think this request is already handeled by #3176.

Thank you for clarifying your pain points. So, there are two issues which are already covered by existing ones, one issue which you would need to create and since we can not simply "switch on" the old attachment system, i suggest to close this issue in favor of fixing the others. If you are a developer: Pull Requests are always welcome 😉 If you have an enterprise subscription i recommend you to use this contact channel to gain more focus to those issues.

@TheTiEr
Copy link
Author

TheTiEr commented Aug 11, 2021

Thanks for your response. Yes implementing these changes will improve the work much for us!

I will close this issue as these changes will be implemented hopefully in the near future. I will open a new issue for a hierarchy organized deck card.

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