Closed michelesr closed 8 years ago
As in request from Alessandro Bogliolo:
"The e-mail address displayed in the page of each event is the one which was said to be accessible only to the ambassadors. We should take the other (optional) field. "
WARNING: 595ef3ef330b8907b78f49f5582421dc96d0821b only avoid that creator personal e-mail is copied in event contact
email during event insertion. For the events already in DB the contact_field
field must be blanked or changed. This can be done from a django shell or admin
interface.
This example shows how to use the django shell in order to blank all the fields:
(codeweek)~/Projects/coding-events $ ./manage.py shell
Python 2.7.10 (default, Sep 7 2015, 13:51:49)
Type "copyright", "credits" or "license" for more information.
IPython 1.2.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]: from api.models.events import Event
In [2]: events = Event.objects.all()
In [3]: for event in events:
...: event.contact_person = ''
...: event.save()
A check on the email adress can be performed before erasing the contact_person
field.
if event.contact_person == event.creator.email:
event.contact_person = ''
event.save()
Thanks @michelesr!
For the contact_person mess, the idea of that code was to prefill that field with the value of the current user's email, if any and let the user decide if she wanted to change it. I looked around the code and I think I found a way to properly initialize and prefill that field (web/views/events.py
, in add_event
). So I will fix that manually.
Thanks for the shell hints on how to clear this field. I think I will keep the current emails there, though, as I suspect usually people leave these two the same and if we clear them, many events will be left without any public contact. I know when this was introduced, so I can check who's affected by this. Probably the best we could do is let these users know after we've fixed the bug and if they want, they can change the field.
As for the scoreboard--definitely only events from the current year should be picked. I think we should make this dynamic, though, and not hardcoded.
The second problem I have with this change is that I'm not convinced we should drop the density-based sorting as it is not fair to smaller countries which organize lots of events to try and compete against other much bigger countries. I will write Alessandro about that.
I'll render the date check dynamic and repush... :-)
It would be nice, thanks. Would you also leave the density sorting back? I will first express my concerns to Alessandro and if he and Annika insist on that, we can always easily remove it.
The old commit was d861c1c484128d4956daa2d353fe44e6bc445144
Nice! Can you remove the aed177d commit? I have fixed that manually in my local copy. After that, I will be able to merge this.
Done
Awesome!
Scoreboard is now related to 2015+ event count instead of 2014+ event density.
As in the request from Alessandro Bogliolo:
"There is a pending task opened by Annika (EU Commission): having a scoreboard based on the number of events (rather than on the density) filtered in order to consider only the events with start date in 2015: http://events.codeweek.eu/scoreboard/ "