Utilitaires de dialogue #503
No reviewers
Labels
No labels
devtype -- backend
devtype -- docs
devtype -- frontend
devtype -- user interface
difficulty -- easy
difficulty -- hard
difficulty -- normal
Doing
domain -- bda
domain -- bds
domain -- cof
domain -- core
domain -- kfet
Good first issue
priority -- high
priority -- low
priority -- medium
priority -- staff-wanted
status -- development
status -- discussion
status -- need review
status -- production
status -- ready to merge
status -- todo
To Do
type -- bug
type -- hygiene
type -- improvement
type -- new feature
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: DGNum/gestioCOF#503
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "Aufinal/dialog_utils"
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?
Ajoute deux type de dialogue avec l'utilisateur :
UserDialog
pour ouvrir un simple dialoguejconfirm
api_with_auth
pour gérer toutes les requêtes API pouvant nécessiter un mot de passeEffet de bord : modifie légèrement le fonctionnement de la détection du capslock.
assigned to @delobell
added 1 commit
08c752f1
- Simplify addcost managementCompare with previous version
Au lieu de
errors
,pre_content
et pourquoi paspost_content
.Aussi vu ce que fait
open
et le nombre de choses qu'on pourrait lui faire faire. Je pense que c'est mieux d'avoir un seul tableau associatif en argument, avec aussi des valeurs par défaut.C'est du pinaillage mais juste
defaults
comme nom pour des attributs quelconques, j'trouve que ça passe mieuxQuand est-ce que sert cette distinction ?
Juste le premier cas semble plus sympa
Le 2e cas me permet de pas avoir de dictionnaire quand on a qu'un seul argument, donc c'est le comportement par défaut ; pour l'instant j'utilise un
dict
uniquement pouraddCost
.Ok effectivement, pour le cas où il n'y a qu'un input c'est sympa. Mais du coup tu peux prendre le code du premier block, puis checker la taille du dict ?
Les deux
window.lock = 0
peuvent se mettre dans un.always(function() { window.lock = 0; })
added 2 commits
582cdeba
- Better callback management236dcb46
- Tweaks to UserDialogCompare with previous version
resolved all discussions
Y sert plus celui-là
Pour clarifier, tu peux appeler le premier
data
qqch du typeinputs
ouinputs_values
ou whateverEt garder
data
pour le callback duon_400
.Le dialogue d'annulation apparaît chez moi...
added 2 commits
29836fd1
- Remove deprecated option4af25621
- More clarity in argument namesCompare with previous version
Si
window.lock
n'est plus accédé ailleurs que dansapi_with_auth
, on peut le virer d'ici (ça fait un truc random de moins qui traîne). Le premier appel de cette fonction va quand même fonctionner même sans créer cette variable avant.Par ailleurs pour pas s’emmêler les pinceaux, on pourrait la renommer en
api_lock
dans cette fonction.added 1 commit
50200371
- api_lock inside kfet.jsCompare with previous version
resolved all discussions
mentioned in commit
dcda67aaf7
merged