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

Question: How to conditionally override resource_type? #447

Open
dgmstuart opened this issue Mar 23, 2021 · 1 comment
Open

Question: How to conditionally override resource_type? #447

dgmstuart opened this issue Mar 23, 2021 · 1 comment
Assignees

Comments

@dgmstuart
Copy link

dgmstuart commented Mar 23, 2021

Is it possible to conditionally set resource_type to "raw" based on attributes of the model instance?

The issue I'm facing is that I have users who want to upload password-protected PDFs. These get rejected by Cloudinary with an error.

In order to upload these, it seems like I need to set the resource_type to "raw", overriding the auto-identified file type (pdf):

The only way I've found so far to do that is with a transformation in the uploader class:

process cloudinary_transformation resource_type: "raw"

...which works, but applies to all files uploaded with this uploader, since process is a class method (?).

Is it possible to set resource_type dynamically for each uploaded file? Or is the approach to have two different uploaders: one which obeys the MIME type (?) and another which always uses "raw"?

If the approach is multiple uploads, is it possible to switch those based on data in the model, or is there always just one uploader per model? I guess that's maybe a question for the CarrierWave project.

Many thanks for your patience 🙏 - I'm inheriting a legacy project which is using this gem and I'm only just getting to grips with how it works 😅

@const-cloudinary
Copy link
Contributor

Hello @dgmstuart, have you tried conditional process ?

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