keystonejs/keystone-classic

`select` on Types.CloudinaryImage doesn't do anything

Open

#4.560 aberto em 31 de jan. de 2018

Ver no GitHub
 (0 comments) (0 reactions) (0 assignees)JavaScript (2.288 forks)batch import
4.x candidatebughelp wantedneeds reproduction

Métricas do repositório

Stars
 (14.656 stars)
Métricas de merge de PR
 (Nenhuma PRs mesclada em 30d)

Description

Expected behavior

According to the documentation I can make the user select an existing CloudinaryImage: http://keystonejs.com/docs/database/#fieldtypes-cloudinaryimage

Actual/Current behavior

This is inside my model:

  image: {
    type: Types.CloudinaryImage,
    autoCleanup: true,
    select: true,
    folder: 'users',
    selectPrefix: 'users',
  },

using it with or without folder and selectPrefix, nothing happens to my UI. It's just the normal "Upload image" button.

Steps to reproduce the actual/current behavior

Add select: true to type: Types.CloudinaryImage

Environment

Software Version
Keystone 4.0.0-beta.5 & 4.0.0-beta.8
Node 8.9.4

Guia do colaborador

Direção de pesquisa
O problema relata que a opção `select` em `Types.CloudinaryImage` não funciona conforme documentado. O bug provavelmente está na implementação do tipo de campo Cloudinary. Comece localizando a definição do campo CloudinaryImage no código fonte do Keystone (fields/types/cloudinaryimage). Verifique como a opção `select` é tratada na lógica de renderização da UI do campo. Compare com outros tipos de campo que suportam `select` (por exemplo, Types.Select) para entender o comportamento esperado. A referência da documentação sugere que `select: true` deve habilitar uma UI para selecionar imagens existentes do Cloudinary. O problema pode ser a falta de uma rota ou controlador para buscar imagens do Cloudinary. Procure por quaisquer alterações recentes ou problemas relacionados no repositório (nota: o problema é de 2018).
Pilha de tecnologia
javascriptnodejsreact
Domain
backendfrontend
Tipo Issue
Bug
DifficultyDificuldade de implementação estimada para um novo contribuidor, de 1 para alterações muito pequenas a 5 para trabalho de nível especializado.
2
Tempo estimadoUm intervalo de tempo aproximado para um colaborador experiente investigar, implementar, testar e preparar um pull request.
1-3 horas
Status da atividadeQuão disponível o issue aparece agora: novo, ativo, obsoleto, bloqueado ou aguardando entrada do mantenedor.
Recente
ClarityCom que clareza o issue explica a mudança esperada, os critérios de aceitação e a próxima etapa.
Claro
Prerequisites
GitNode.js
Simpatia para novatosUma pontuação de 1 a 100 que estima o quão acessível este issue é para colaboradores iniciantes.
60