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

Document sending metadata via the REST API #1275

Closed
Tolriq opened this issue Dec 15, 2023 · 9 comments
Closed

Document sending metadata via the REST API #1275

Tolriq opened this issue Dec 15, 2023 · 9 comments
Labels

Comments

@Tolriq
Copy link
Contributor

Tolriq commented Dec 15, 2023

Hi,

Currently testing Sharry and it perfectly fit my needs so thanks a lot for this nice tool.

I'd like to add automatic upload to an alias via the API for some use case but would need to be able add add a description during the upload.
Seems we need to pass a meta field with json in the multipart form data, but it's definition is not documented.
List of mandatory fields, field formats, ... Is there anything somewhere that I missed ?

@eikek
Copy link
Owner

eikek commented Dec 17, 2023

There is this: https://eikek.github.io/sharry/openapi/sharry-openapi.html#tag/Shares-Upload/operation/sec-upload-post it shows how meta looks like. Does this help? It is the generated api docs, linked from here

@eikek eikek added the question label Dec 17, 2023
@Tolriq
Copy link
Contributor Author

Tolriq commented Dec 17, 2023

Thanks, I completely missed the link and directly jumped to the examples :( So sorry for the noise.

To avoid opening new threads, just 2 quick questions.

Do you take feature requests?
I'd love to have the search in the upload page to also search in the description.
Uploads to aliases having a different validity.
Infinite duration for the aliases. (I tried to increase the max-validity to 3650 days but aliases are still limited to 12 months).

Basically the usage would be a public share with a fixed name, where users can upload log files with a description so I can find their files when they contact me. And those logs expires a lot faster than the 12 months (or infinite) duration of the alias.

@eikek
Copy link
Owner

eikek commented Dec 19, 2023

Do you take feature requests?

In theory yes :) but I'm currently and in the near future not able to do much myself

I think that an increased configured validity not showing up in the alias view is a bug. I can't remember having done anything special for aliases right now. I'm not sure I understand completely: if you want a shorter validity for uploads to an alias, you should be able to set it per alias. So you can have short and long validity periods.

@Tolriq
Copy link
Contributor Author

Tolriq commented Dec 19, 2023

Unless I missunderstood something about the aliases, the goal is to have an alias with infinite duration and a well know name.

So users can use that alias forever to upload data to it. But I'd like the data uploaded to have small expiration date. Even passing the validaty via the API is not applied the alias values is used.

If the alias does not expire and the duration time is only about shares created in it then it's ok.

For the search in description this looks easy but I know nothing about scala and the system you use :(

Maybe you can confirm and I can try.

Would be in https://github.com/eikek/sharry/blob/master/modules/backend/src/main/scala/sharry/backend/share/Queries.scala#L193

Just add a var to RShare.Columns.description and add it in Sql.or(name.like(qs), sid.like(qs), aliasName.like(qs)) ?

@eikek
Copy link
Owner

eikek commented Dec 20, 2023

Ah yes this is confusing. The validity that is set for an alias applies to the uploads done through it. The alias itself never expires.

Would be in https://github.com/eikek/sharry/blob/master/modules/backend/src/main/scala/sharry/backend/share/Queries.scala#L193

Just add a var to RShare.Columns.description and add it in Sql.or(name.like(qs), sid.like(qs), aliasName.like(qs)) ?

Yes that looks like the correct place! You can use a val instead of var. When done, you can run sbt fix to apply source formatting rules (if you want to open a pr). 🙏🏼

@Tolriq
Copy link
Contributor Author

Tolriq commented Dec 20, 2023

Ah yes this is confusing. The validity that is set for an alias applies to the uploads done through it. The alias itself never expires.

Thanks, yes UI is not very clear about that, but this solves all my issues about alias so this is nice :)

For the PR, I'll need to figure out how this compiles and build locally (On windows :p) to test first, so will be after the holidays.

Thanks for the help and answers.

@Tolriq
Copy link
Contributor Author

Tolriq commented Jan 6, 2024

So now that search works in description I have one last request :)

Seems that auto deletion for unpublished shares are not auto cleaned by design. So my single alias where people upload there is not cleaned up.
From another discussion it seems that you do not want to change that, but do you think it possible that you add a delete button in the share list or even better a multi select / delete solution?
Currently it's at least 4 clicks per share to fully delete (Open / Details / Delete / Yes)

@eikek
Copy link
Owner

eikek commented Jan 6, 2024

Hi @Tolriq thank you for your PR! For the other request, can you maybe create a new issue? And… if you can find that discussion, it would be great to link it. I sometimes forget very quickly my thoughts :) It is also always possible that I change my mind - right now I can't really remember all the details.

Currently by design only published shares are removed, because they can expire. Non-published ones don't really expire and thus aren't removed automatically. I see two options from the top of my head: another expiry date or setting to also remove unpublished shares or to automatically publish uploads via an alias (if configured to do so). If that meets more your needs, I would prefer to not add this "quick delete feature", tbh. For now as a work around you could probably create a script to delete many shares.

@Tolriq
Copy link
Contributor Author

Tolriq commented Jan 6, 2024

Opened #1294 thanks.

@Tolriq Tolriq closed this as completed Jan 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants