keystonejs/keystone-classic

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

Open

#4.560 geöffnet am 31. Jan. 2018

Auf GitHub ansehen
 (0 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)JavaScript (2.288 Forks)batch import
4.x candidatebughelp wantedneeds reproduction

Repository-Metriken

Stars
 (14.656 Stars)
PR-Merge-Metriken
 (Keine gemergten PRs in 30 T)

Beschreibung

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

Contributor Guide

Research-Richtung
Das Problem meldet, dass die `select` Option auf `Types.CloudinaryImage` nicht wie dokumentiert funktioniert. Der Fehler liegt wahrscheinlich in der Implementierung des Cloudinary Feldtyps. Beginnen Sie damit, die CloudinaryImage Felddefinition im Keystone Quellcode (fields/types/cloudinaryimage) zu finden. Überprüfen Sie, wie die `select` Option in der UI Rendering Logik des Feldes behandelt wird. Vergleichen Sie mit anderen Feldtypen, die `select` unterstützen (z. B. Types.Select), um das erwartete Verhalten zu verstehen. Der Dokumentationshinweis legt nahe, dass `select: true` eine UI zum Auswählen vorhandener Bilder aus Cloudinary aktivieren sollte. Das Problem könnte ein fehlender Route oder Controller Aufruf zum Abrufen von Bildern aus Cloudinary sein. Suchen Sie nach aktuellen Änderungen oder verwandten Issues im Repository (Hinweis: Das Issue stammt aus dem Jahr 2018).
Tech Stack
javascriptnodejsreact
Domain
backendfrontend
Issue Type
Fehler
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
2
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-3 Stunden
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Frisch
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
GitNode.js
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
60