cccc70338db8ea95da299bca504b2caed14c9964
9 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Inna
|
67faa1a266 |
send-gift: rediseño al original — es la tienda, pero regalando
El original lo dice en su propio texto ("los objetos disponibles son los mismos
de la tienda") y lo confirma su JS, que usa #store-list y .store-add-button: el
regalo NO tiene catálogo propio, es la tienda con el correo a otro personaje.
Nosotros teníamos una tabla aparte (home_item) con 8 objetos y precios en euros.
Ahora send-gift monta StoreBrowser en modo `gift`: mismo catálogo (3068 ítems,
PD/PV), mismo carrito con cantidades y las cuatro formas de pago. Antes NO tenía
Stripe: solo SumUp, PD y PV.
Dos pasos, como el original: primero #char-select-div (personaje de origen,
destino, confirmación y token) y solo al pulsar "Mostrar Regalos" aparece el
catálogo. Se borran SendGiftForm, /api/gift/checkout y lib/gift (ya no los usa
nadie); la tabla home_item se queda en la BD, sin usar.
Tres cosas que el usuario pidió y que estaban mal:
- El formulario va con `noValidate`: los avisos los damos nosotros en rojo
(#show-gif-response), no el navegador.
- "Mostrar Regalos" ahora valida contra el SERVIDOR (que el personaje de origen
sea tuyo, que el destino exista y que el token sea correcto). Antes elegías
objetos para descubrir al final que el destino no existía.
- BUG REAL: el nombre del destino distinguía mayúsculas. `characters.name` es
`utf8mb4_bin`, así que "innakh" NO encontraba a "Innakh" (comprobado: 0
resultados; con COLLATE, 1). `findCharacterByName` busca sin distinguir y
devuelve el nombre CANÓNICO, que es el que va al comando SOAP.
La validación vive en lib/gift-check y la usan las dos rutas: /api/gift/check (el
botón) y /api/gift/send, que revalida porque el cliente puede saltarse el paso 1.
También se quita del texto "El pago se realiza mediante SumUp": el original no lo
dice y además ya era falso con cuatro formas de pago.
Verificado: innakh / INNAKH / InNaKh resuelven a "Innakh"; token malo y destino
inexistente salen en rojo sin pasar al catálogo. Con 500 PD de saldo de prueba,
2 copias de un ítem de 200 pasan el cobro (deliveryFailed por el worldserver
caído, con su reembolso) y 3 dan insufficientPd: el servidor cobra por copias.
Datos de prueba borrados.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
Inna
|
24248bc603 |
store: el árbol de categorías, igual que el original (colores y sin fantasmas)
Investigadas las 750 categorías de la BD contra el HTML real del original. Los
ítems estaban perfectos (554 hojas, 3068 ítems, mismo contenido en cada una: no
faltaba ninguno). Todo lo roto era de categorías:
- 45 CATEGORÍAS FANTASMA, todas con nombre de código ("11-1", "23-10"). El seed
dedujo el árbol de los códigos de las hojas ("11-1-1" => padre "11-1"), pero
el original NO siempre pinta ese nivel: en 45 hojas el "-1-" del código no
corresponde a nada y cuelgan directas de su raíz. Ahora se lee el anidamiento
real (<ul>/<li>): 705 categorías (20 + 131 + 554) en vez de 750.
- El nombre de una categoría NO es texto plano, es HTML, y lo estábamos
aplanando: 141 nombres perdían su color y 40 cabeceras el suyo. Hay dos
mecanismos y los dos hacen falta: la clase en la CABECERA, que sustituye a
first-brown para colorear la categoría entera ("Brujo" en color de brujo), y
los <span class="no-toggle X"> dentro del nombre (clases y las etiquetas
[Nivel 232 a 245] / (DPS) en otro tono).
- 21 nombres TRUNCADOS en Tokens de Armadura: guardábamos "Guerrero" donde el
original dice "Guerrero, Sacerdote, Druida" (solo se quedó el primer span).
El HTML se trocea en el SERVIDOR (`parseCategoryName`) y al cliente le llegan
solo texto + nombre de clase, así que no hay HTML de la BD entrando en el DOM.
El texto sin color va suelto, NO envuelto en <span>: el tema tiene
`span { color: #fff }` y lo pondría blanco en vez de heredar el de la cabecera.
`name` pasa a VARCHAR(512): con el HTML, el más largo mide 198 y no cabía en 191.
El name_en se genera en el propio seed traduciendo solo el TEXTO y respetando
las etiquetas, así que sql/store_category_en.sql sobra y se borra.
gen_store_catalog.py regenera el seed entero (categorías del HTML, ítems de la
BD, que ya estaban verificados) y es reproducible byte a byte.
Verificado en el navegador contra el original: mismo árbol, 0 categorías con
nombre de código, "[Nivel 232 a 245]" en marrón tenue y los colores de clase
oficiales (Guerrero #C79C6E, Sacerdote blanco, Druida #FF7D0A). En inglés
también, conservando los colores.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
Inna
|
f232f0fc5f |
store: poder cambiar la cantidad de un mismo artículo en el carrito
El carrito era un conjunto: añadir dos veces el mismo ítem no hacía nada y el
botón se quedaba en "Añadido". Ahora cada línea lleva sus copias, editables con
un <input number> en la columna Cant, y volver a pulsar Añadir suma una (mismo
patrón que el carrito de send-gift, que ya lo hacía así).
Ojo con los dos "cantidad" que conviven, que no son lo mismo:
`home_store_item.quantity` es el LOTE que entrega cada copia (Paño de lino = 20)
y `copies` es cuántas veces se compra la línea. Por eso la fila enseña "3 × 20"
y el total de la columna Cant sigue siendo unidades (60), como en el original.
Cada copia se manda al SOAP como una entrada propia (`2589:20 2589:20`), que es
justo lo que ya sabía trocear sendStoreItems (12 por correo) y parsear
fulfillStoreOrder: el formato del pedido de tarjeta no cambia.
El servidor no se fía del cliente: priceStoreCart recibe {id, copies}, valida las
copias (1..MAX_COPIES, como el MAX_QTY de send-gift), rechaza el carrito si algún
id no existe y recalcula los totales como precio*copias contra la BD.
Verificado contra la API con saldo de prueba, no solo en la interfaz: con 500 PD
y un ítem de 200, 2 copias (400) pasan el cobro y 3 (600) dan insufficientPd. Si
el servidor ignorase las copias ambas darían lo mismo, así que el corte exacto
entre 2 y 3 prueba que multiplica. Comprobado también que el reembolso del
deliveryFailed devuelve los 400 PD, y que copias=0 o 101 se rechazan.
El CSS del input va con `#cart-list` por especificidad, no por gusto: el tema
define `input[type=number] { width: 290px }` y se carga el último para ganar la
cascada, así que un `.store-copies` a secas perdía y el input salía de 290px
reventando la tabla (send-gift se libra porque usa estilo en línea).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
Inna
|
e500bd7a84 |
store: precios en euros en el carrito y mínimo real de las pasarelas
El carrito enseñaba PD/PV aunque eligieras tarjeta, y por defecto ya presuponía saldo. Ahora se muestran SIEMPRE las dos monedas y se apaga la que no se va a cobrar con el método elegido, así que no presupone nada ni se contradice. Los euros por línea van con hasta 3 decimales a propósito: un ítem en PV con precio impar cuesta medio céntimo (75 PV = 0,375 €), y redondear cada línea a 2 haría que las líneas no sumaran el total (0,38 + 0,38 = 0,76 contra un total de 0,75). El total sí va a céntimos: es el importe que se cobra de verdad. Y con mínimo 2 decimales, que es dinero: "1,50 €", no "1,5 €". El formateo va por Intl con el locale de la web, así que en español sale con coma; antes el selector interpolaba el número crudo y decía "0.75 €" con punto. Mínimos de las pasarelas: SumUp ya estaba en 1 € y Stripe estaba en 0,50 €, ahora también 1 €. Estaban sueltos en la ruta; se centralizan en `lib/store-pricing`, un módulo PURO que importan tanto la ruta como el componente, para que el carrito enseñe exactamente lo que se valida y se cobra. `storeEuroTotal` pasa a vivir ahí (una sola implementación) y lib/store lo envuelve con un guard: si alguien cambia PD_PER_UNIT o VP_PRICE_FACTOR sin tocar store-pricing, revienta al primer uso en vez de cobrar mal en silencio (esos módulos tocan BD y no pueden llegar al bundle del cliente, de ahí la duplicación, igual que en PaymentMethodSelect). Por debajo del mínimo, la opción de tarjeta se desactiva y dice "Mínimo 1,00 €" en vez de dejarte pulsar Enviar para que la API la rechace. El método efectivo se deriva en el render (si el carrito baja del mínimo con tarjeta ya elegida, cae al saldo) en vez de sincronizarlo con un setState en un efecto, que provocaría renders en cascada. Verificado en el navegador: con 0,375 € las dos tarjetas salen desactivadas y elegido el saldo; con 1,50 € se habilitan. Las dos líneas de 0,375 € suman el total de 0,75 €. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Inna
|
2daf920c01 |
store: nombres de ítem en el idioma de la web (desde home_item_data)
El catálogo original solo tiene el nombre en español, así que /en/store venía
mostrando los ítems en español. Ahora salen de `home_item_data` (extraída de
los DB2 del cliente, commit
|
||
|
Inna
|
14ebd1e1f1 |
store: previsualización del render del ítem al pasar el ratón
Replica el preview del store original: un icono en el cuadro del ítem que, al pasar el ratón, muestra el render del objeto. El CSS ya estaba en el tema (nw-st-tooltip-w / nw-st-img-tooltip / nw-img-display, copiado del original); solo faltaban el markup y las imágenes. - Los 545 PNG se sirven desde nw-images/nw-displays/ en vez de enlazar al servidor original, para no depender de un tercero que puede cortarlo. - Solo lo llevan los ítems equipables (610 de 3068): el resto no tiene apariencia, igual que en el original. El dato ya estaba en la columna `preview` de home_store_item y llegaba hasta el componente sin usarse. - El icono va con `fas`, no con el `fa` suelto del original: cargamos Font Awesome 6, donde solo .fas/.fa-solid activan la fuente, y el `fa` de FA4/5 no pintaría nada sin el shim de compatibilidad. Descartado el visor 3D de wowhead: zamimg sirve el meta del modelo con lista blanca de orígenes (403 desde nuestro dominio, 200 solo desde wowhead.com), así que solo funcionaría proxeando sus assets para saltarse esa comprobación. Verificado en el navegador: oculto por defecto, visible en hover, imagen 200. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Inna
|
8e16ba8391 |
store: iguala el carrito y el cuadro de ítem al diseño original
Comparado contra el store original (ultimowow /es/store-bennu) con una sesión real: markup, CSS y clases que aplica su power.js. Cinco causas distintas: - Los nombres de ítem salían azules: el layout declaraba `const whTooltips`, que queda en el ámbito léxico del script y NO crea propiedad en `window`, que es de donde tooltips.js lee la config -> se ignoraba entera. Ahora `window.whTooltips`, con colorLinks+iconizeLinks (el original no define whTooltips y usa esos defaults; sus enlaces acaban con clases `icontinyl q4`). renameLinks sigue en false: el texto sale de nuestra BD, en español. - tooltips.js solo recorre el DOM al cargar, así que los enlaces que monta React (hoja del árbol, carrito) no se teñían. Se pasan por $WowheadPower.refreshLinks(), igual que hace el original tras cada AJAX. - globals.css redefinía .item-box/.item-name/.item-img-box/.max-left-table2, que el tema nw-ryu ya trae del original, y con más especificidad ganaba la cascada. El peor: un `border-collapse` que anulaba el `border-spacing: 0 8px` del tema, que es lo que separa las filas del carrito. - Faltaban la caja "Carrito - <REINO>" y "Personaje seleccionado: <nombre>" (coloreado por clase), que el original sí tiene. - El total de la columna "Cant" mostraba el número de líneas en vez de la suma de cantidades: un ítem que entrega un mazo de 20 debe contar 20, no 1. Verificado con navegador contra un build de producción: el nombre del ítem sale con clases `icontinyl q4` y color rgb(163,53,238), el mismo valor exacto que devuelve el original. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Inna
|
f0b006404c |
store: pagar también con Stripe y SumUp (tarjeta), además del saldo PD/PV
Selector de forma de pago en el carrito (Saldo PD/PV · Stripe · SumUp), como el resto de servicios. Con tarjeta, el carrito se convierte a euros (100 PD = 1 €, 200 PV = 1 €), se guarda como pedido y se entrega tras confirmarse el pago. - BD: tabla home_store_order (ref, cuenta, personaje, items, importe) para no depender del límite de metadata de la pasarela (sql/home_store_order.sql). - lib/store: storeEuroTotal, createStoreOrder, fulfillStoreOrder. - paid-services: servicio 'store' (fulfill = enviar el pedido por order_ref); la entrega la dispara service-success/reconciliación/webhook como los demás. - /api/store/send: rama provider stripe/sumup (crea pedido + checkout, mínimo 1 €/0,50 €) además del pago con saldo. - StoreBrowser: selector Saldo/Stripe/SumUp; con tarjeta redirige a la pasarela. - i18n Store (payMethod/payBalance/payStripe/paySumUp/confirmCard/amountTooLow) y Paid.store (title/success). Verificado: euros 200PD+28PV=2,14 €, pedido y fulfill por order_ref (SOAP real pendiente, worldserver caído). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Inna
|
026fbcb81c |
Implementa la tienda /store (catálogo BENNU: 750 categorías, 3068 ítems)
Porta la tienda de ítems/transfiguración del sistema antiguo: elegir personaje → árbol de categorías (3 niveles) → carrito → enviar por correo. Se paga con el saldo PD o PV de la cuenta (cada ítem lleva su precio y moneda). - BD: home_store_category (árbol por code "1-1-1") + home_store_item (mismos item_id, nombres, iconos, precios y moneda que el original; 2947 en PD, 121 en PV). Seed en sql/store_catalog.sql, extraído del HTML real. - lib/store.ts: getStoreCatalog (árbol anidado), getStoreBalances, priceStoreCart (precios REALES de BD), purchaseStoreCart (cobro atómico PD+PV con FOR UPDATE y reembolso si el envío SOAP falla; `.send items` troceado a 12/correo). - API: GET /api/store/catalog (tras elegir personaje) y POST /api/store/send. - components/StoreBrowser.tsx: selector de personaje, árbol colapsable (ítems montados solo al abrir), carrito con totales PD/PV, enviar, modal de resultado. - página /store con la info y el título "Tienda - REINO". Enlaces de ítems e iconos por wowhead/zamimg (con tooltip y locale). El enlace ya existía en AccountTools. i18n namespace Store (es/en). CSS del árbol/carrito/modal. Verificado: catálogo E2E (750 cats/3068 ítems), cobro atómico + reembolso y detección de saldo insuficiente (cuenta 15). SOAP real sin probar (worldserver caído en este entorno). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |