puffin ha scritto: ↑

02/02/2018, 10:49

Sul taglio.... a me verrebbe questo flusso:

- fino a chiusura CHIAMATA, tutto come ora
- a chiusura CHIAMATA si blocca tutto (non viene fatta l'assegnazione in automatico come ora)
- il vincente DEVE AVERE la possiblità di INDICARE IL GIOCATORE TAGLIATO (quindi una nuova sezione, nuovi comandi e nuovi controlli su tagli consentiti o meno)
- una volta confermato il giocatore TAGLIATO succedono 2 cose
1 - viene TAGLIATO il giocatore in QUESTIONE e quindi recuperati i CREDITI relativi
2 - viene ASSEGNATO il nuovo giocatore.
- Quindi la palla torna all'admin che fa partire il nuovo turno.

Ti torna?

L'inghippo è che qui costringi il vincitore della chiamata ad azioni ulteriori (scegli il taglio, conferma il taglio) che da remoto è da verificare quanto siano funzionali.

Mi torna ma permane il problema del recupero crediti.
Fin quando si tratta di "un'assegnazione errata" lo capisco, ma in questo caso è evidente che si tratta di una sostituzione, di un taglio volontario.
A quanto pare è una meccanica abbastanza diffusa nelle aste, compresa quella di settembre: ad esempio una squadra potrebbe avere un reparto pieno e scegliere comunque (se il regolamento interno lo consente) di sostituire uno dei giocatori che si era aggiudicato, perdendo i crediti che aveva speso quel giocatore.

Per questo suggerivo un'opzione per far sì che l'amministratore possa decidere come debba comportarsi il sistema in caso di taglio: se la casella è spuntata, ogni taglio viene rimborsato, altrimenti no.
In questo modo si accontentano più utenti, oltre a tornare utile per le aste di riparazione.

Personalmente non vedo la necessità di automatizzare quelle azioni che si possono ottenere con pochi clic, aggirando il problema grazie alle funzioni a disposizione (in questo caso rose libere per consentire più di 25 giocatori, taglio del giocatore demandato all'amministratore e ad egli comunicato via chat), mentre trovo più urgente semplificare quelle azioni comuni e frequenti che con le impostazioni attuali diventano macchinose, quali appunto il taglio di un giocatore.

Scenario 1 (come funziona adesso, senza opzione):
Una squadra si aggiudica un giocatore
scrive in chat chi vuole tagliare
l'amministratore taglia il giocatore
poi deve andare in setup utenti, togliere tanti crediti quanti sono stati rimborsati per il giocatore tagliato (e deve farsi anche dei calcoli)
infine salvare
(in alternativa, imposta il costo del giocatore da tagliare a 0, poi lo taglia)

Scenario 2 (con opzione per non rimborsare i crediti):
Una squadra si aggiudica un giocatore
scrive in chat chi vuole tagliare
l'amministratore taglia il giocatore
fine

Lo scenario 1 diventa ancora più macchinoso se il giocatore da tagliare era stato aggiudicato durante l'asta corrente, poiché i soldi spesi per quel giocatore sono da considerare persi, sprecati.
In questo caso bisogna sia modificare il prezzo del giocatore da tagliare, sia aggiornare l'ammontare dei crediti per quella squadra.

Simodium ha scritto: ↑

02/02/2018, 11:51

Mi torna ma permane il problema del recupero crediti.

Perchè scusa? Quale punto del flusso descritto non ti torna ai fini del recupero crediti?
La procedura descritta sopra sarebbe fatta proprio per consentirti di recuperare i crediti del taglio una volta che ti sei aggiudicato un giocatore (non è in funzione è una ipotesi di funzionamento per includere la possibilità del taglio).

Simodium ha scritto: ↑

02/02/2018, 11:51

Per questo suggerivo un'opzione per far sì che l'amministratore possa decidere come debba comportarsi il sistema in caso di taglio: se la casella è spuntata, ogni taglio viene rimborsato, altrimenti no.

Questa è un altro discorso, e si, il comportamento di cui sopra si può legare ad una opzione che se spuntata lavora in quel modo se non è spuntata lavora come fa ora (cioè non considera un taglio ma un annullamento di assegnazione).

Simodium ha scritto: ↑

02/02/2018, 11:51

...trovo più urgente semplificare quelle azioni comuni e frequenti che con le impostazioni attuali diventano macchinose, quali appunto il taglio di un giocatore.

Il discorso qui, anche considerando i due scenari proposti è il punto di partenza.
Il sistema nasce per gestire un'ASTA (che prevede assegnazioni) non un MERCATO DI RIPARAZIONE (che prevede TAGLI) e che quindi, di conseguenza, non contempla quell'operazione se non con macchinosi interventi come quelli che hai elencato ma ripeto, il motivo è che nasce per altri scopi.

Il flusso che proponevo sopra poteva essere una soluzione a questo problema non so se mi spiego... (anche se al momento la vedo difficile, perchè ormai siamo in corsa...)