Ir a la documentación
Ruby

Archivos

`files.list`, `list_all`, `iterate`, `get`, `download`, `list_links`, `list_all_links`, `iterate_links`, `create_link`, `revoke_link`, `stats`, `upload`, `delete` y `delete_many`.

Todos los métodos

files.rb
page = client.files.list(kind: "pdf", sort: "largest")file = page.items.first links = client.files.list_all_links(file[:id])p links.map { |link| [link[:url], link[:downloads]] } stats = client.files.statsputs stats.dig(:totals, :files), stats.dig(:uploaded, :bytes) File.binwrite(file[:filename], client.files.download(file[:id]))

Cada archivo que guarda el buzón, adjuntos enviados y recibidos y los archivos subidos a él: la página Archivos de la aplicación. download devuelve los bytes como String binaria, que File.binwrite guarda sin cambios. Los enlaces son los enlaces de descarga con los que salió un archivo, con cuántas veces se descargó cada uno, y stats es la pestaña Analíticas.

list, list_all e iterate admiten q:, kind: y sort:, y también direction: (inbound, outbound o uploaded), address:, los archivos de una dirección comparada sin distinguir mayúsculas y minúsculas, y since: y until:, un Time, un DateTime o una String ISO 8601. since: incluye su momento y until: se detiene antes. Una Date de Ruby se envía como fecha sin hora, que esta lista lee como medianoche UTC.

q: busca en el nombre del archivo y en su tipo. kind: es image, pdf, audio, video o text, y sort: es newest, el valor por defecto, oldest, largest o name. OpenEmail::FILE_KINDS, OpenEmail::FILE_SORTS y OpenEmail::FILE_DIRECTIONS nombran las opciones. list devuelve una OpenEmail::Page, y list_all devuelve todos los archivos en un solo Array. iterate pasa cada archivo a un bloque y solo obtiene la página siguiente cuando el bucle la necesita. Sin bloque devuelve un Enumerator.

Leer necesita files:read, y subir, eliminar y publicar o revocar enlaces necesitan files:write, que incluye files:read. Una clave creada antes de que los archivos tuvieran ámbitos propios recibió los correspondientes. Una clave sin el ámbito se rechaza con un 403 insufficient_scope, y scope_missing? es true en el error. Una clave limitada a direcciones o dominios concretos solo ve los archivos que llegaron a ellos, así que no ve los archivos subidos para todo el espacio de trabajo.

download guarda el archivo entero en memoria, así que descarga los archivos muy grandes de uno en uno.

Subir y eliminar

upload.rb
upload = client.files.upload(File.binread("report.pdf"), filename: "report.pdf", content_type: "application/pdf")client.files.delete(upload[:id]) if upload[:deletable] invoice = client.files.upload(Pathname("invoice.pdf"))puts invoice[:filename], invoice[:mimeType] result = client.files.delete_many(["file_0c4e7a91d2b84f63a5e19b7d", "file_6bb640f5b99e47deb758f1f5"])result[:kept].each { |kept| puts "#{kept[:filename]} #{kept[:reason]}" }

upload guarda los bytes tal cual, hasta 100 MB, con el nombre indicado en filename:, y devuelve el archivo. Un envío lo adjunta como {fileId: upload[:id]} en los attachments de emails.send. Pasa content_type:, o bytes que lleven su propio tipo, y cualquier otra cosa se guarda como application/octet-stream. Nunca se reintenta, porque un segundo intento guardaría una segunda copia.

Los bytes son una String binaria, un IO o un Pathname. Un Pathname o un File no necesitan ninguno de los dos argumentos nombrados: el nombre es el del propio archivo, y el tipo sale de su extensión cuando la gema la conoce, como .pdf o .png. Un archivo subido en Rails trae sus propios original_filename y content_type. Los bytes sueltos no llevan nombre, así que una String o un StringIO sin filename: lanza ArgumentError antes de enviar nada.

Una subida puede durar 600 segundos, o el timeout del cliente si es mayor, y timeout: fija otro límite para una sola llamada. Un cliente construido con timeout: 0 espera lo que tarde la subida.

Solo se puede eliminar un archivo subido del que nada depende, y deletable y usage en cada archivo lo indican de antemano. delete rechaza cualquier otro archivo con un 409 file_in_use, lanzado como OpenEmail::ConflictError. delete_many admite hasta 100 ids, elimina lo que puede e informa del resto en kept, cada uno con su motivo, y en missing. Ninguno de los dos se reintenta. Un 404 en un segundo delete tras una respuesta perdida significa que el primero funcionó, y un segundo delete_many informa de esos archivos en missing.