ereuse/devicehub-django
8
0
Fork 0
Code Issues 6 Pull requests 6 Packages Projects Releases Wiki Activity

WIP: Changed annotation syntax and added States/StatesDefinitions #37

Draft
rskthomas wants to merge 86 commits from feature/states into main
pull from: feature/states
merge into: ereuse:main
Conversation 3 Commits 86 Files changed 51 +1897 -485
rskthomas commented 2024-12-11 18:54:34 +00:00
Owner
Copy link

Parte 1 y 2 de ereuse/projectes#108

  1. 1. Cambios de estructura de annotation y bifurcación hacia user properties y system properties:
    1. 1. Renombrar tabla annotations a system_properties
    2. 2. Cambio cosmético pero conceptual: renombrar annotations a properties en todo el sistema (vistas, etc.)
    3. 3. Mover user properties a una nueva tabla. Motivo: las system properties son inmutables, en cambio user properties son mutables.
    4. 4. Permitir edición de user properties
    5. 5. Trigger CRUD de user properties hacia device_log
      1. 1. NOTA: Actualmente no se encuentra la tabla logs (próximo PR junto con funcionalidad notas)

Se encuentran también los cambios comentados por @cayop en ereuse/devicehub-django#31.

  1. 2. (Nuevo) Estados predefinidos definidos por institución, esta información solo puede configurarla el admin de la institución.
    1. 1. creación de tabla de definición de estados (state_definition) | institución | orden | estado |
    2. 2. creación de tabla estados (states) | institución | usuario | fecha | estado | snapshot_uuid |. donde estado es una string, y la tabla state_definition solo entra en juego en el momento de seleccionar y validar el nuevo estado predefinido (softkey)
    3. 3. Trigger cualquier CRUD (modificación) hacia device_log
      1. 1. NOTA: Actualmente no se encuentra la tabla logs (próximo PR junto con funcionalidad notas)
    4. 4. Vistas y endpoints para hacer CRUD

Es posible reordenar los StateDefinition mediante una lista draggable:

image

Se aplican cada State asociado a un device. Por el momento me pareció prudente solamente borrar el último estado (lista tipo LIFO - estilo funcionalidad undo).

image

Actualmente no está implementada la funcionalidad de notas, pero en el próximo PR (notas + tabla device_log ) lo implemento. Me parecio prudente poder agregar una nota al mismo tiempo que se cambia el estado (sólo como atajo, no linkeadas lógicamente):

image

Además, he agregado un pequeño ícono de ayuda para dar más contexto a la vista. Sólamente se muestra si se le pasa como context "help_text":

image

Parte 1 y 2 de ereuse/projectes#108 1. [x] 1. Cambios de estructura de **annotation** y bifurcación hacia **user properties** y **system properties**: 1. [x] 1. Renombrar tabla **annotations** a **system_properties** 2. [x] 2. Cambio cosmético pero conceptual: renombrar **annotations** a **properties** en todo el sistema (vistas, etc.) 3. [x] 3. Mover **user properties** a una nueva tabla. Motivo: las **system properties** son inmutables, en cambio **user properties** son mutables. 4. [x] 4. Permitir edición de **user properties** 5. [ ] 5. Trigger CRUD de **user properties** hacia **device_log** 1. [ ] 1. NOTA: Actualmente no se encuentra la tabla logs (próximo PR junto con funcionalidad notas) Se encuentran también los cambios comentados por @cayop en ereuse/devicehub-django#31. 2. [x] 2. (Nuevo) **Estados** predefinidos definidos por institución, esta información solo puede configurarla el admin de la institución. 1. [x] 1. creación de **tabla de definición de estados** (`state_definition`) `| institución | orden | estado |` 2. [x] 2. creación de **tabla estados** (`states`) `| institución | usuario | fecha | estado | snapshot_uuid |`. donde `estado` es una string, y la tabla `state_definition` solo entra en juego en el momento de seleccionar y validar el nuevo estado predefinido (softkey) 3. [ ] 3. Trigger cualquier CRUD (modificación) hacia **device_log** 1. [ ] 1. NOTA: Actualmente no se encuentra la tabla logs (próximo PR junto con funcionalidad notas) 4. [x] 4. Vistas y endpoints para hacer CRUD - - - Es posible reordenar los StateDefinition mediante una lista draggable: ![image](/attachments/a4e0a722-1602-4316-8d38-ac9c351aedee) Se aplican cada State asociado a un device. Por el momento me pareció prudente solamente borrar el último estado (lista tipo LIFO - estilo funcionalidad undo). ![image](/attachments/4819b249-48e4-459f-876b-dddde1525a9f) Actualmente no está implementada la funcionalidad de notas, pero en el próximo PR (notas + tabla device_log ) lo implemento. Me parecio prudente poder agregar una nota al mismo tiempo que se cambia el estado (sólo como atajo, no linkeadas lógicamente): ![image](/attachments/94a7dd24-6f8f-4f09-98f9-35f57be70e0d) Además, he agregado un pequeño ícono de ayuda para dar más contexto a la vista. Sólamente se muestra si se le pasa como context "help_text": ![image](/attachments/1f186be7-1318-4370-ae76-bc5a7e97ffd6)
image.png
106 KiB
image.png
130 KiB
image.png
133 KiB
image.png
73 KiB
rskthomas added 55 commits 2024-12-11 18:54:35 +00:00
rskthomas added 3 commits 2024-12-11 20:36:15 +00:00
rskthomas added 1 commit 2024-12-12 19:10:40 +00:00
rskthomas added 1 commit 2024-12-12 19:48:54 +00:00
rskthomas added 2 commits 2024-12-12 21:18:48 +00:00
rskthomas added 1 commit 2024-12-13 19:08:12 +00:00
rskthomas added 1 commit 2024-12-13 19:31:00 +00:00
rskthomas added 1 commit 2024-12-13 20:06:48 +00:00
rskthomas added 2 commits 2024-12-14 19:45:47 +00:00
rskthomas added 2 commits 2024-12-16 19:20:47 +00:00
rskthomas added 1 commit 2024-12-16 20:50:56 +00:00
rskthomas added 1 commit 2024-12-17 16:35:34 +00:00
rskthomas changed title from WIP: States and StatesDefinitions to Changed annotation syntax and States/StatesDefinitions 2024-12-17 17:27:55 +00:00
rskthomas requested review from cayop 2024-12-17 17:54:16 +00:00
rskthomas requested review from pedro 2024-12-17 17:54:16 +00:00
rskthomas changed title from Changed annotation syntax and States/StatesDefinitions to Changed annotation syntax and added States/StatesDefinitions 2024-12-17 20:24:03 +00:00
pedro commented 2024-12-18 10:27:27 +00:00
Owner
Copy link

Nos lo hemos mirado @cayop y yo y aquí vienen nuestras notas

De momento puedes probar en demo.ereuse.org

Pronto vamos a habilitar dominios lab1.ereuse.org para dejar una instancia en marcha con estas cosas

Nos lo hemos mirado @cayop y yo y aquí vienen nuestras notas De momento puedes probar en demo.ereuse.org Pronto vamos a habilitar dominios lab1.ereuse.org para dejar una instancia en marcha con estas cosas - [ ] Bugs 1. [ ] No puedo crear tag <https://demo.ereuse.org/evidence/> 2. [ ] <https://demo.ereuse.org/lot/1/property/add> 1. [ ] No se puede editar 2. [ ] No se puede crear key que ya existe (problema UNIQUE) 3. [ ] <https://demo.ereuse.org/device/9ee50ab0456259a71b35306f280eb9ee3c8e95d0b3e47b68752c59ae934c00b0/> 1. [ ] No se puede crear key que ya existe (problema UNIQUE) 4. [ ] De todas estas acciones no hay ningún log aquí <https://demo.ereuse.org/device/7b769bd6e9191d5ff163fa4a206b9220dad10c47b45d210d3d4d31d586f6a4b6/#log> 5. [ ] Si edito estado por otro que ya existe UNIQUE constraint failed <https://demo.ereuse.org/admin/states/edit/1/> 6. [ ] La nota del log no se ve 7. [ ] Cuando se cambia un estado sale un mensaje en verde tal como "Action to 'TODO' has been added", cambiar por "State changed from Previous-State to Current-State" - [ ] Cambios propuestos 1. [ ] Quitar tabla de Current State (en caso de necesitar ver o revertir, tienes el log para revisar) 2. [ ] Cambiar la forma en que se añaden notas o estados - [ ] renombrar botón Action por "Change state (Current state)", dando click a un estado, lo cambia inmediatamente, en el selector no sale el mismo estado donde ya estoy (Current state) - [ ] añadir botón "Add nota", que hace modal/formulario de campo de descripción 3. [ ] Añadir comando de django que se crean estos estados por defecto: 1 INBOX, 2 VISUAL INSPECTION, 3 REPAIR, 4 INSTALL, 5 TEST, 6 PACKAGING, 7 DONATION, 8 DISMANTLE
leandro commented 2024-12-18 11:22:53 +00:00
Owner
Copy link

Unos comentarios:

  • veo algo de confusión entre estados y acciones. Mientras que INBOX puede ser un estado, el resto son acciones y creo genera confusión. Se habla de ready for ... or done: por ejemplo: REPAIR es una acción. Quiere decir (ya reparado: operational) o clasificado FOR-REPAIR o READY-FOR-REPAIR (veo en la pantalla "A reparar"). Lo mismo para el resto.

  • En relación a UNTP, DONATION es una forma concreta de transferencia. O bien cambiarlo por READY-FOR-TRANSFER o añadir READY-FOR-TRANSFER como estado.

  • Aplica a dispositivos y también a lotes?

Unos comentarios: - veo algo de confusión entre estados y acciones. Mientras que INBOX puede ser un estado, el resto son acciones y creo genera confusión. Se habla de ready for ... or done: por ejemplo: REPAIR es una acción. Quiere decir (ya reparado: operational) o clasificado FOR-REPAIR o READY-FOR-REPAIR (veo en la pantalla "A reparar"). Lo mismo para el resto. - En relación a UNTP, DONATION es una forma concreta de transferencia. O bien cambiarlo por READY-FOR-TRANSFER o añadir READY-FOR-TRANSFER como estado. - Aplica a dispositivos y también a lotes?
rskthomas changed title from Changed annotation syntax and added States/StatesDefinitions to WIP: Changed annotation syntax and added States/StatesDefinitions 2024-12-18 11:53:32 +00:00
pedro commented 2024-12-18 12:18:57 +00:00
Owner
Copy link

Hola @leandro

Si te parece, vamos a continuar como hemos definido cayo y yo, almenos para esta iteración; y dejamos tus comentarios como retrospectiva posterior. Motivo: porque va a haber mucho trabajo en estabilizarlo, cerramos esta fase, y podríamos volver a reflexionar en dónde estamos y hacia dónde vamos más adelante. Ahora mismo creo que necesitamos ir cerrando almenos estas funcionalidades para que vengan las siguientes y poder tenerlas para que ekoa nos devuelva feedback. Además, esta rama se está haciendo muy grande y nadie quisiera alargar mucho esta discusión ahora.

También he movido tu comentario donde creo que tiene más sentido que es en el Proyecto ISOC F3.2, cuando trabajemos esa parte ereuse/projectes#84 (comment)

Te respondo ya a los puntos de tus comentarios como 1, 2 y 3

  1. @cayop y yo lo tenemos muy claro, después de muchas horas de reunión decidimos evitar y desvincularnos del concepto de "acciones". En el modelo planteado no existen las acciones, existen los estados y las notas, de tal forma que es muy flexible para los operadores y organizaciones. Estamos partiendo de unos estados por defecto (porque ahora no hay estados por defecto, y para reducir la fricción inicial de UX) en base a cómo ekoa trabaja (que por cierto es similar a cómo lo hace tau) [1]. De hecho, esta funcionalidad es para ekoa, para que pueda dejar de usar glpi con una herramienta más avanzada o específica para esto. Y ellos con los estados, y ciertas "notas" ya tienen suficiente. Si alguien quiere cambiar los nombres de los estados, hay un menú para hacerlo que @rskthomas desarrolló y que está muy bien.

  2. Pusimos INBOX porque era lo más parecido a "Recepción", otras ideas, bienvenidas sean (excepto "Reception")

  3. En cuanto a DONATION, es como sale en [1], es lo que necesita ekoa. Aquí no estamos entrando en cómo lo necesita UNTP, y de momento las notas y los estados solo aplican a dispositivos. Es probable que necesitemos algo parecido con los lotes, pero de momento, es suficientemenete complejo y nos queremos quedar con la sencillez como lo hemos definido en ereuse/projectes#108

[1]
(esta info está recogida en el informe del viaje de argentina también)

image

Hola @leandro Si te parece, vamos a continuar como hemos definido cayo y yo, almenos para esta iteración; y dejamos tus comentarios como retrospectiva posterior. Motivo: porque va a haber mucho trabajo en estabilizarlo, cerramos esta fase, y podríamos volver a reflexionar en dónde estamos y hacia dónde vamos más adelante. Ahora mismo creo que necesitamos ir cerrando almenos estas funcionalidades para que vengan las siguientes y poder tenerlas para que ekoa nos devuelva feedback. Además, esta rama se está haciendo muy grande y nadie quisiera alargar mucho esta discusión ahora. También he movido tu comentario donde creo que tiene más sentido que es en el *Proyecto ISOC F3.2*, cuando trabajemos esa parte https://farga.pangea.org/ereuse/projectes/issues/84#issuecomment-2624 Te respondo ya a los puntos de tus comentarios como 1, 2 y 3 1. @cayop y yo lo tenemos muy claro, después de muchas horas de reunión decidimos evitar y desvincularnos del concepto de "acciones". En el modelo planteado no existen las acciones, existen los estados y las notas, de tal forma que es muy flexible para los operadores y organizaciones. Estamos partiendo de unos estados por defecto (porque ahora no hay estados por defecto, y para reducir la fricción inicial de UX) en base a cómo ekoa trabaja (que por cierto es similar a cómo lo hace tau) [1]. De hecho, esta funcionalidad es para ekoa, para que pueda dejar de usar glpi con una herramienta más avanzada o específica para esto. Y ellos con los estados, y ciertas "notas" ya tienen suficiente. Si alguien quiere cambiar los nombres de los estados, hay un menú para hacerlo que @rskthomas desarrolló y que está muy bien. 2. Pusimos INBOX porque era lo más parecido a "Recepción", otras ideas, bienvenidas sean (excepto "Reception") 3. En cuanto a DONATION, es como sale en [1], es lo que necesita ekoa. Aquí no estamos entrando en cómo lo necesita UNTP, y de momento las notas y los estados solo aplican a dispositivos. Es probable que necesitemos algo parecido con los lotes, pero de momento, es suficientemenete complejo y nos queremos quedar con la sencillez como lo hemos definido en https://farga.pangea.org/ereuse/projectes/issues/108 [1] (esta info está recogida en el informe del viaje de argentina también) ![image](/attachments/156ef078-a33e-493d-a3ef-08b8b9a1de35)
image.png
24 KiB
rskthomas added 1 commit 2024-12-18 12:56:00 +00:00
rskthomas added 1 commit 2024-12-18 15:38:29 +00:00
rskthomas added 3 commits 2024-12-18 16:15:41 +00:00
rskthomas added 1 commit 2024-12-19 21:17:38 +00:00
rskthomas added 2 commits 2024-12-19 23:18:00 +00:00
rskthomas added 1 commit 2024-12-19 23:28:21 +00:00
rskthomas added 5 commits 2024-12-20 18:37:49 +00:00
rskthomas added 1 commit 2024-12-20 19:12:25 +00:00
This pull request has changes conflicting with the target branch.
  • api/views.py
  • dashboard/views.py
  • device/models.py
  • device/templates/details.html
  • device/views.py
  • evidence/forms.py
  • evidence/models.py
  • evidence/parse.py
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin feature/states:feature/states
git checkout feature/states

Merge

Merge the changes and update on Forgejo.
git checkout main
git merge --no-ff feature/states
git checkout main
git merge --ff-only feature/states
git checkout feature/states
git rebase main
git checkout main
git merge --no-ff feature/states
git checkout main
git merge --squash feature/states
git checkout main
git merge --ff-only feature/states
git checkout main
git merge feature/states
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
cayop
pedro
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: ereuse/devicehub-django#37
No description provided.
Delete branch "feature/states"

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?