#6276 createNewWarehouse methods migrated from silex to salix #1850
Labels
No Milestone
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: verdnatura/salix#1850
Loading…
Reference in New Issue
No description provided.
Delete Branch "6276-createNewWarehouse"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
WIP 6276-createNewWarehouseto WIP: 6276-createNewWarehouseWIP: 6276-createNewWarehouseto WIP: #6276-createNewWarehouseRecomendación: mirar métodos de silex para comprobar que no se pierda la funcionalidad. Creo que algún método no lo he llamado igual, preguntarme en caso de duda.
WIP: #6276-createNewWarehouseto #6276 createNewWarehouse methods migrated from silex to salix@jgallego @alexm @sergiodt falta por revisar un método assignCollection. No he creado el test por eso... Parece que ha habido un cambio en la base de datos que afecta a este. Sergio y yo sospechamos que puede venir de la vista ticketState o ticketStateToday. Lo revisaré con Pablo o alguno de vosotros y después añadiré el test
@jgallego @sergiodt @alexm Sergio y yo hemos comprobado que todos los backs devuelvan los datos como en silex. Creo que hay un método en el que necesita probarlo en test. En el redmine está apuntado.
@ -20,2 +20,3 @@
"Loggable"
]
],
"CodeGPT.apiKey": "CodeGPT Plus Beta"
esto a nivel equipo lo subimos @alexm ?
Lo voy a quitar, yo lo plantearía con @jsegarra en un reunión de salix.
Este archivo sólo sube en caso de añadir palabras para la extensión de Code Spell Checker.
Yo tengo la misma que tu y no me ha cambiado nada.
Descartaría los cambios d este fichero si no aporta valor
@ -0,0 +1,61 @@
const UserError = require('vn-loopback/util/user-error');
module.exports = Self => {
veo un enfoque extraño, se crea este método en collection, pero dentro no trata con colecciones, sino que añade a un ticket, porque no lo mueves a ticket o miras si en ticket ya existe uno que te sirva?
El propio modelo de sale (sale.js L87) ya hace la validación de disponible.
Valoraria que sergio usara directamente ticket/addSale
@ -0,0 +10,4 @@
('ItemBarcode','deleteByItemAndCode','WRITE','ALLOW','ROLE','employee'),
('Collection','addItem','WRITE','ALLOW','ROLE','employee'),
('ExpeditionPallet', '*', 'READ', 'ALLOW', 'ROLE', 'production'),
('MobileAppVersionControl', '*', 'READ', 'ALLOW', 'ROLE', 'production'),
aqui no es employee?
@sergiodt @jgallego Me podéis pasar una lista con el rol para cada acl?
@sergiodt mira a vore qui ha de gastar cada pantalla i com ho tenies ara i poseu els rols concrets
@ -339,2 +339,2 @@
"No tickets to invoice": "No hay tickets para facturar"
}
"No tickets to invoice": "No hay tickets para facturar",
"No hay tickets para sacar": "No hay tickets para sacar",
no puede estar en castellano
@ -0,0 +1,34 @@
module.exports = Self => {
aqui no se puede usar el nativo desde front y no cremo el archivo?
@jgallego solo permite eliminar por id.
@ -0,0 +52,4 @@
let packing;
if (result) packing = result.itemPacking;
if (!packing) packing = 1;
crear un redmine para refactorizar esto y el proc itemShelving_add
aqui no tendria que ponerse un 1 en el codigo, sino que sino hay se le pase null al proc, y ya seria el proc internamente el que lo gestiona, de hecho el codigo esta.
además no hay que multiplicar aqui por la cantidad tampoco, que se el pase las etiquetas, y el procedimiento que es el que sabe el vPacking que lo multiplique, este método quedaria mas simple.
Tarea creada: https://redmine.verdnatura.es/issues/6776 y una rama añadida con el back creado.
@ -0,0 +39,4 @@
};
let itemShelvings = await models.ItemShelving.find(filterItemShelvings, myOptions);
const [alternatives] = await models.ItemShelving.rawSql('CALL vn.itemShelving_getAlternatives(?)',
si eso se usa en el if, porque no lo mueves dentro, así en los casos que no haya itemShelvings no es necesario ejecutarlo?
@ -0,0 +36,4 @@
fields: ['code'],
where: {
itemFk: realIdItem
quitar salto
@ -0,0 +38,4 @@
if (!shelving) throw new UserError($t('Shelving not valid'));
await models.ShelvingLog.create({
esto porque no se hace automatizado como el resto de modelos? ejemplo ticket
@jgallego @alexm Perquè necessitaria dos cridaes, una per traure el id i un altra per fer el insert amb el id.
@ -0,0 +1,60 @@
const UserError = require('vn-loopback/util/user-error');
este solo con un filtro de loopback no lo puedes conseguir sacar en el explorer, así no es necesario crear este método?
@ -0,0 +95,4 @@
if (tx) await tx.commit();
} catch (e) {
if (e.message == $t('The sale can not be tracked')) {
cannot
@ -0,0 +1,61 @@
module.exports = Self => {
Self.remoteMethodCtx('getFromSectorCollection', {
confirma con @sergiodt que esto pasa así a salix, o se separa..o hay alguna tarea para separarlo
@jgallego Separarlo en quin sentit ? És el back que trau les linies de previa amb les seues ubicacions.....
Crec que m'he confós tenia en ment allò de ticket or collection, tot clar.
@ -58,3 +58,3 @@
FROM vn.sectorCollection`, [], options);
expect(sectorCollection.numberRows).toEqual(0);
expect(sectorCollection.numberRows).toEqual(1);
ejecuta antes de borrar SELECT COUNT(*) numberRows
FROM vn.sectorCollection`, [], options);
FROM vn.sectorCollection
y así quitas el uno y el test lo haces dinamico
@ -12,2 +13,3 @@
"description": "Identifier"
}
},
"truckFk": {
al poner la relacion este bloque lo puedes quitar
@ -0,0 +10,4 @@
"saleFk": {
"id": true,
"type": "number",
"forceId": false
esto en que caso es necesario?
@jgallego es necesario en 2 backs de saleTracking: mark y updateTracking. Lo dejo? O prefieres un rawSql?
me refiero al parametro "forceId": false
Lo quito, creo que lo puse al principio se me olvido poner id: true
@ -0,0 +24,4 @@
}
try {
await Self.create({
si simplemente se hace el create? porque no lo hace segio usando el put desde front?
@jgallego para dar un error personalizado.
@sergiodt realment es necesita?
@ -0,0 +48,4 @@
try {
const [[item]] = await Self.rawSql('CALL vn.item_getInfo(?,?)', [code, warehouseFk], myOptions);
if (!item?.available) throw new UserError($t('We do not have availability for the selected item'));
No hace falta usar $t, UserError traduce por defecto.
Ahora el error se maneja desde Sale.js
@ -0,0 +26,4 @@
const [assignedCollection] = await Self.rawSql('SELECT @vCollectionFk');
const {'@vCollectionFk': collectionFk} = assignedCollection;
if (!collectionFk) throw new UserError($t('There are not picking tickets'));
No hace falta usar $t, UserError traduce por defecto.
@ -0,0 +153,4 @@
return Self.rawSql(query, [ticketId], options);
}
async function setState(source, id, options) {
Aço se pot refactoritzar per
const STATES= {
'PRECHECKER': 'PREVIOUS_CONTROL',
'CHECKER': 'ON_CHECKING'
}
if(STATES[source])
@ -0,0 +28,4 @@
});
let fields = ['id', 'appName'];
if (workerFk)
Javascript tiene una forma muy sencilla de 'fusionar' arrays
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/concat
@ -0,0 +40,4 @@
fields,
};
return await Self.findOne(filter);
en un return no hace falta poner 'await'
Bing:
@ -3069,0 +3125,4 @@
isMain = TRUE,
itemPackingTypeFk = NULL;
REPLACE vn.parking SET id = 9991011, sectorFk = 9991, code = 'A-01-1', pickingOrder = 1;
Diria que es mejor enfoque cambiar el propio insert de vn.parking y de vn.shelving por lo que quieres.
Que hacer un insert que luegos vas a hacer un replaces.
O hacer el insert directamente
(Esto aplica a todos los repalces que haces)
Tampoco acabo de ver el adaptar las fixtures a ids tan altos, como lo ves @jgallego ?
cuantos menos ids mejor, si se puede cambiar directo en las fixtures mejor, sino intentar evitar el id
replaces cambiados. Los ids en este caso son necesarios por lo hablado con @sergiodt .
@ -0,0 +1,18 @@
-- Place your SQL code here
INSERT INTO `salix`.`ACL` (model, property, accessType, permission, principalType, principalId)
Estan duplicados los ACLs?
@alexm Sí, elimino ese script? el bueno es 00-newWarehouse
Lo elimino
@ -268,14 +268,8 @@ class VnMySQL extends MySQL {
arguments, model, ctx, opts, cb);
}
isLoggable(model) {
Esto te lo ha dicho Juan?
Esto cambia el como se loggean todos los cambios
Sí @alexm , @jgallego . Me hacía falta para poder utilizar la función account.getMyuserId (o parecido) dentro de los procedimientos. Si no, coge el usuario del sistema. En caso de duda, habría que hablarlo con @juan
De momento he puesto que el modelo SaleBuy sea loggable, tal cual hemos hablado @alexm y yo. Le he preguntado por rocket a @juan a ver que opina... @sergiodt @jgallego .
Cambios realizados para que todos tengan acceso acceso a userId, no solo loggable. Revisado con @juan
@ -0,0 +56,4 @@
quantity = quantity * packing;
await Self.rawSql('CALL vn.itemShelving_add(?, ?, ?, NULL, NULL, ?, ?)',
En salix para poder loggear los cambios en CALLs hace falta que el myOptions tenga el userId
https://redmine.verdnatura.es/issues/6776 se ha pasado este procedimiento a esta tarea. lo añado ahí para que quien la coja lo tenga puesto.
@ -0,0 +40,4 @@
let itemShelvings = await models.ItemShelving.find(filterItemShelvings, myOptions);
const [alternatives] = await models.ItemShelving.rawSql('CALL vn.itemShelving_getAlternatives(?)',
[shelvingFk], myOptions
En salix para poder loggear los cambios en CALLs hace falta que el myOptions tenga el userId
@ -0,0 +52,4 @@
};
}
throw new UserError($t('This pallet does not exist'));
No hace falta usar $t, UserError traduce por defecto.
Método reemplazado por llamada a directa al modelo de loopback
@ -16,2 +14,4 @@
type: ['string']
},
],
returns: {
Si no lo requiere sergio especificamente, normalmente con terminar el procedimiento sobra, no hace falta devolver true
Lo quito
@ -0,0 +90,4 @@
const buy = await models.Buy.findById(buyFk, myOptions);
if (buy.itemOriginalFk) await models.SaleBuy.create({saleFk, buyFk}, myOptions);
} catch (e) {
throw new UserError($t('The sale can not be tracked'));
No hace falta usar $t, UserError traduce por defecto.
@ -0,0 +60,4 @@
where: {code},
}, myOptions);
if (!state) throw new UserError($t('this state does not exist'));
No hace falta usar $t, UserError traduce por defecto.
@ -0,0 +69,4 @@
const attributes = {
isChecked,
originalQuantity,
isScanned
Tambien se puede hacer
isScanned: !!isScanned
y te ahorras el valor por defecto.Pero no creo que haya una preferencia de hacerlo de una manera o de otra
En la tabla saleTracking -> el valor por defecto is NULL, no es solo true o false. Lo comenté con @sergiodt y quedamos así.
@ -72,2 +73,3 @@
if (await models.ACL.checkAccessAcl(ctx, 'Sale', 'isInPreparing', '*')) return;
const isInPreparing = await models.ACL.checkAccessAcl(ctx, 'Sale', 'isInPreparing', '*');
if (!ctx.isNEwInstance && isInPreparing) return;
isNEwInstance o isNewInstance.
Añadir test para este caso
@jorgep En tabla silexACL están los rol para cada procedimiento. En caso de ser employee subir a production.
@ -0,0 +1,31 @@
const UserError = require('vn-loopback/util/user-error');
module.exports = Self => {
Self.remoteMethodCtx('assignCollection', {
nombre simplemente assign al estar en el contexto collection se asume que es una coleccion
@ -0,0 +1,167 @@
module.exports = Self => {
Self.remoteMethodCtx('getSalesFromTicketOrCollection', {
getSales
@ -0,0 +62,4 @@
let observations = ticket.observaciones.split(' ');
for (let observation of observations) {
const salesMan = ticket.salesPersonFk;
salesPerson
@ -0,0 +92,4 @@
if (sale.ticketFk == ticketFk) {
sale.placements = [];
for (const salePlacement of placements) {
let placement;
si solo se usa en el if, porque no la defines dentro?
@jgallego que quieres decir?
la variable let placement moverla 2 linea abajo, incluso valorar si es const
debería ser const e ir dentro. Lo cambio
@ -0,0 +50,4 @@
if (machineWorker) {
const {maxHours} = await models.MachineWorkerConfig.findOne({fields: ['maxHours']}, myOptions);
const hoursDifference = (Date.vnNow() - machineWorker.inTime.getTime()) / (60 * 60 * 1000);
const isHimSelf = userId == machineWorker.workerFk;
isHimself
@ -0,0 +1,62 @@
module.exports = Self => {
Self.remoteMethod('return', {
getAlternative
@ -0,0 +1,50 @@
module.exports = Self => {
Self.remoteMethod('card', {
get
@ -0,0 +8,4 @@
},
accepts: [
{
arg: 'itemFk',
barcode
@ -0,0 +34,4 @@
const [[itemInfo]] = await Self.rawSql('CALL vn.item_getInfo(?, ?)', [itemFk, warehouseFk], myOptions);
const barcodeItems = await Self.rawSql('SELECT vn.barcodeToItem(?) as realIdItem', [itemFk], myOptions);
quitar esta llamada, dentro de item_getInfo ya se llama a barcodeToItem por tanto itemInfo ya contiene el id que se busca
@sergiodt es correcto o quieres los barcodes tambien?
@ -0,0 +1,106 @@
const UserError = require('vn-loopback/util/user-error');
module.exports = Self => {
Self.remoteMethodCtx('mark', {
mark es poco descriptivo, buscad un nombre que diga algo mas sobre el cometido del método.
@jgallego saleMarked bien?
aqui se hacen cambios en varias tablas, imagino que es fruto de una acción muy concreta. Cual es? porque tal vez ese sea el nombre mas descriptivo @sergiodt ? ej setPicked?
@ -0,0 +5,4 @@
accessType: 'WRITE',
accepts: [
{
arg: 'code',
barcode
@ -0,0 +45,4 @@
const [[item]] = await Self.rawSql('CALL vn.item_getInfo(?,?)', [code, warehouseFk], myOptions);
if (!item?.available) throw new UserError('We do not have availability for the selected item');
await Self.rawSql('CALL vn.collection_addItem(?, ?, ?)', [item.id, quantity, ticketFk], myOptions);
crea redmine, aqui no deberia llamar a collection_addItem sino a remoteMethodCtx('addSale' para reutilizar codigo, y eliminar vn.collection_addItem
@sergiodt poniendo addSale como está ahora te sirve?
@ -0,0 +16,4 @@
Object.assign(myOptions, options);
const isOperator = await Self.findById(userId, myOptions);
if (!isOperator) await Self.create({workerFk: userId}, myOptions);
No sé si esto ya lo hablamos, me suena que sí, pero por asegurar.
Aquí habéis contemplado no crear este método y llamar al create nativo de loopback gestionando el error en caso de que ya exista?
@jgallego Sí, acabo de hablar con Sergio y hemos quedado en cambiarlo a como dices tú.
@ -0,0 +20,4 @@
if (typeof options == 'object')
Object.assign(myOptions, options);
const [info, okPacket, {collectionFk}] = await Self.rawSql('CALL vn.collection_assign(?, @vCollectionFk); SELECT @vCollectionFk collectionFk',
si no usas info y okPacket porque los recuperas?
No se pueden hacer dos llamadas?
@jgallego No funciona bien, no está abriendo y cerrando la conexión a bd si lo hago en 2 llamadas. Puedo probar a usar un new ParametizedSql como en cloneWithEntries. O hacer como en transferSales y acceder directamente a la posición del array.
const [, , {collectionFk}]
@ -0,0 +46,4 @@
const [sales] = await Self.rawSql('CALL vn.sale_getFromTicketOrCollection(?)',
[id], myOptions);
const isPicker = source == 'CHECKER';
picker i checker no son el mateix..
@ -0,0 +52,4 @@
return {
id: itemShelving.id,
itemFk: itemShelving.itemFk,
longName: item ? item.longName || `${item.name} ${item.size}` : '',
esto donde se muestra? mirar con @sergiodt ya que esto debería en todo caso hacerlo front, intentar mostrar siempre el longName si no lo hay no mostrar nada, siempre debe haberlo
Vale, le envio por separado, como propiedades el name y el size y ya el muestra en el front longname o los otros. Hablado con @sergiodt .
@ -0,0 +63,4 @@
for (let observation of observations) {
const salesPerson = ticket.salesPersonFk;
if (!observation.startsWith('#') && !observation.startsWith('@')) return;
esto para que sirve? si todos los que envian tienen que hacerlo..conviene moverlo dentro del propio envio no?
Pregunto a @alexm
Si la función tuviese un test si que vería más correcto separarlo.
Si solo se usa una vez y no tiene test. Lo dejaria dentro tambien (como decia @jgallego)
@ -0,0 +154,4 @@
async function setState(source, id, options) {
const states = {
'PRECHECKER': 'PREVIOUS_CONTROL',
@sergiodt ací no pots pasar desde front el codi correcte i evitem fer esta conversió?
Corregido, lo pasará desde el front.
Comentario
@ -0,0 +64,4 @@
}, myOptions);
if (hoursDifference >= maxHours)
await models.MachineWorker.create({machineFk: machine.id, workerFk: userId}, myOptions);
Si en els dos casos fa el mateix, fica fora de les condicions
@ -292,3 +292,3 @@
try {
const userId = opts.httpCtx && opts.httpCtx.active?.accessToken?.userId;
const {userId} = opts;
I en ningun cas es
opts.httpCtx.active?.accessToken?.userId
?En el archivo loopback>common>mixins>loggable, se ha aplicado cambios para recoger directamente el userId. Cambio realizado por Juan.
@ -0,0 +1,34 @@
module.exports = Self => {
Self.remoteMethod('delete', {
description: 'Delete an ItemBarcode by itemFk and code',
accessType: 'READ',
Seria WRITE
@ -0,0 +26,4 @@
if (typeof options == 'object')
Object.assign(myOptions, options);
await Self.destroyAll({
No se pot fer directe contra el model?
DELETE
.../ItemBarcodes?barcode=...&itemFk=...
Solo se puede por id
@ -0,0 +47,4 @@
return itemShelvings.map(itemShelving => {
const item = itemShelving.item();
const carros = alternatives.filter(alternative => alternative.itemFk == itemShelving.itemFk);
Mejor variable en ingles
@ -0,0 +86,4 @@
await Self.updateTracking(ctx, saleFk, originalQuantity, code, isChecked, null, isScanned, myOptions);
try {
const buy = await models.Buy.findById(buyFk, myOptions);
const {itemOriginalFk}