feroda/gasistafelice — comment on commit 1209d5390c1a354d24cf8c53add98fbef4b0a55a
File:  line 0
By feroda:

Please move comment near lines you refer it. We will think deeper about it, but I point you that
withdrawal with null=True is set according to [GUIDELINES (line 49)](https://github.com/feroda/gasistafelice/blob/master/doc-dev/source/GUIDELINES.rst)

> Cercare di massimizzare i campi ``blank=True``. Lo specifico perché è importante non ragionare su "cosa l'utente dovrebbe scrivere di un determinato oggetto, ma qual è il minimo sforzo con cui può farlo".

So: no need to specify withdrawal at order creation time, but this does not mean that for a "sane" order, withdrawal appointment can be unset (nor that must be set ... we have to think about it)

Probably the best solution (seeing that Gassosa p.e. has many delivery places for one order) is binding to an order a list (`ManyToManyField`) of generic appointment (Event) implemented by a Model like:

class Event(models.Model):
title
place
start_datetime
end_datetime

and

class GASSupplierOrderEvent(Event):

flavour = models.CharField with CHOICES = ('delivery', 'withdrawal', 'other')

or... no no (I am thinking... :)) it is definetly better to have:

class TaggedEvent(models.Model)

....see implementation of taggings....

which adds many arbitrary tags for an event.
**Tags could be not only 'delivery' or 'withdrawal', but also 'gassosa: delivery, gasdimontagna:delivery' or 'des:delivery'**

This model pattern excites me :) and in **view layer** we can simplify as much as we want to hide "tag stuff" and ... for a first implementation
(that we are not doing now), leave forms that we have already de[ployed
This model pattern is more fluid, extensible and will match more generic and fashionable needings of GASses.

And we could also findo something already done in Django about event management....

(going to add link to this discussion among comments on line 127/128)