metalab / mos Goto Github PK

automatically apply the existing fixtures as described in HACKING during provisioning with ansible.
improve the documentation about how to start the server.

In Django Shell (using stage + correct venv):
from django.contrib.auth.models import User
User.objects.all()
gives "DatabaseError: no such table: auth_user"

The MOS should have the option in the login page to reset forgotten user passwords, and mail a new one to the e-mail address listed in the database.

Use case:

1. User has forgotten her password

Expected result:

1. User can click on "forgotten password" on login page
2. User enters their username and/or e-mail address
3. MOS sends an e-mail with a confirmation link (no auto-reset)
4. When confirmation link is clicked, MOS generates and mails new password

Actual result (metalab.at-specific):

1. User needs to send e-mail to core@
2. Admins manually reset password

Additional comments:
The confirmation link is important to avoid problems with people randomly resetting other users' passwords. Ideally step 2 in "Expected result" should also have a captcha.

When starting up a development server, I get the following warning:

/Users/thp/src/mos/devel/lib/python2.6/site-packages/django/conf/__init__.py:75: DeprecationWarning: The ADMIN_MEDIA_PREFIX setting has been removed; use STATIC_URL instead.
  "use STATIC_URL instead.", DeprecationWarning)

billing not in INSTALLED_APPS or imported anywhere.

These files should probably be removed by now / saved elsewhere (not in the source repo):

metalab/templates/mahnungsmail_2009-05-27.txt
metalab/templates/mahnungsmail_2009-05-28.txt

This could be done either by hand or with piptools. I'm not sure, which is more realistic for this project.

HACKING only mentions the core fixtures not cal, members, ...

Wie need this view as a sortable table.
At the moment it's really hard to tell who debts how much because we can't sort it.

There are various csrf_token errors when using ajax with POST.
At least when deleting events.

The website has the "cellar door" view here: https://metalab.at/cellardoor/

AFAIK it's not currently used (the machine there is broken?). Do we want to revise that, do we want to improve that page? Should we make it more generally-useful (e.g. as a smaller/scalable version that people can pin e.g. on their OS X Dashboard)? It looks quite nice, and does it's thing, so removing it might be a waste.

stage.metalab.at/announce gives a 404 (or 500?) when sending. This will have to work before we go live with 1.5 branch.

We had no idea who to contact for a colliding event this week. It would be good to display the MOS username of the user who created an event so people know who to contact in case of questions.

• Creating events shows no feedback other than loading the main page again
• Updating events shows no feedback at all
• Deleting events shows no feedback at all
• #181
• #168
• Event creation dialog
  • the calendar popup has a transparent background
  • #164
  • 99% of all events have the same end day as start day, don't force the user to enter it twice
  • don't allow entering events without an end time
  • show potential conflicts before the event is created (should be the same for updates)
  • allow entering recurring events

The "Letzte Änderungen" list on the MOS-Frontpage doesn't update anymore:
https://metalab.at/

It seems like the following package was meant to be used at some point (or was even used at some point), but right now it's not referred from the main urls.py:

https://github.com/Metalab/mos/tree/django_1_4_compatibility/usbherelist

If it's not going to be used, it's probably a good idea to remove it (it will always be available in the SCM history should somebody want to revive that package in the future).

If we decide to remove it, "metalab/media/usbherelist" can also be removed.

When updating a calender event after pressing the "update" button there is no response and hence unclear if it succeeded or not. Button is working though, only feedback is missing.

For example, using Fabric

Summary:
When adding a new calendar event from the / page it will not show up in the list of events after reloading the stat page. The event is available in the calendar view http://localhost:8000/calendar/

How to reproduce:
On the startpage click “create new event…”
Enter data for the event.
Click create.
Wait a moment for the backend to do it's stuff and imagine some user feedback in the meantime.
Reload the page normally.

Expected Results:
If the event is in the near future, it should be listed in the events list on the frontpage.

Actual Results:
The events list shows an additional “New event…” entry instead of the event data.

Regression:
On a local installation on OS X 10.8.3 running python 2.7.2.
$ pip freeze
Django==1.4.5
PIL==1.1.7
Unipath==1.0
distribute==0.6.31
django-extensions==1.1.1
icalendar==3.3
python-dateutil==2.1
pytz==2013b
six==1.3.0
wsgiref==0.1.2

eg:
ORGANIZER:X, Y
URL (see #11)

https://tools.ietf.org/html/rfc5545

Says "Enter a valid e-mail address." to my valid email address w/ new shiny and super long domain ending. Probably some regex foo that checks for length or a field validation against a white-list, either should be dropped.

Edit: Same bug for the standard email field.

There are huge avatar images, at the moment they are loaded as fullsize image, thumbnail them and save bandwidth.

it's down and the next person touching it is going to do everything differently anyway. Right now the code requests resources which have gone 404.

How to reproduce:

On a local mos instance: Go to the startpage or /calendar page and click login. On the login page enter your credentials for the local mos installation and click login.

Actual result:

MOS returns:

Forbidden (403)
CSRF verification failed. Request aborted.
Help
Reason given for failure:
CSRF token missing or incorrect.

In general, this can occur when there is a genuine Cross Site Request Forgery, or when Django's CSRF mechanism has not been used correctly. For POST forms, you need to ensure:
Your browser is accepting cookies.
The view function uses RequestContext for the template, instead of Context.
In the template, there is a {% csrf_token %} template tag inside each POST form that targets an internal URL.
If you are not using CsrfViewMiddleware, then you must use csrf_protect on any views that use the csrf_token template tag, as well as those that accept the POST data.
You're seeing the help section of this page because you have DEBUG = True in your Django settings file. Change that to False, and only the initial error message will be displayed.
You can customize this page using the CSRF_FAILURE_VIEW setting.

Expected result:

User is logged in and returned to the same page but with user status.

Regression:

$ python --version
Python 2.7.2 (On OS X 10.8.3)

$ pip freeze
Django==1.4.5
PIL==1.1.7
Unipath==1.0
distribute==0.6.31
django-extensions==1.1.1
icalendar==3.3
python-dateutil==2.1
pytz==2013b
six==1.3.0
wsgiref==0.1.2

Looking at the file:

https://github.com/Metalab/mos/blob/django_1_4_compatibility/cal/feeds.py

The query uses: startDate__gte=datetime.datetime.now()

This works fine, but does not show events that have started in the past, but for which the end time has not been reached yet. I propose that the query is updated to something like that:

(endDate IS NULL AND startDate >= now) OR (endDate >= now)

Every form in the MOS should include {% csrf_token %}

While logged in as admin in
http://127.0.0.1:8000/admin/members/

Klick on the link names “auth“ which directs you to:
http://127.0.0.1:8000/admin/calendar/auth/

Actual result:
404

Expected result:
I don't know what actually should happen there, but certainly not a 404.

http://spaceapi.net/

Instead of MySQL, we should use PostgreSQL.

Migration tools

Mediawiki Compatibility

Since the edit menu stays on screen without feedback after deleting an event, this is a frequent issue.

Getting a message:

ImproperlyConfigured: Requested setting USE_I18N, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.

currently the first_name,last_name,email fields are only visible after the user was added.

I guess if we are sending mails to our users, it would be nice to give them a check-box to choose which language they prefer (and maybe which second language too).
:)

Since this comes with Django 1.9 as default, I'm not sure it's worth it to implement in MOS.
Problems with un-stripped fields include lines not being correctly matched to members when importing payment statements.

When adding a new member the "bank account mandate reference" should be created automatically (currently user id == mandate reference) if bank account is present

Hi, currently we're manually sending new users a "Welcome Mail".
Which annoys me, since my crappy mail-client is doing horrible things when playing copy-pasta.

I'm not sure how difficult it is to implement: But at the moment it's 'hard' for people to tell in which room events are at the overview page http://metalab.at/calendar/
Scrolling down to see the additional detail is not user friendly. :)

Hi, it would be great to have the ability to view the change (also by who does them) history system wide.
Just letting this issue there, so we know, that there is this need - no stress to implement if it's difficult to.

Following the instructions from the HACKING file, I managed to get to step 7, which gave the following output:

(devel) fukushima ~/s/mos & python manage.py generate_secret_key
Traceback (most recent call last):
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/core/management/__init__.py", line 179, in fetch_command
    app_name = commands[subcommand]
KeyError: 'generate_secret_key'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/mw/src/mos/mos/settings/common.py", line 9, in <module>
    from .secret_key import *
ImportError: No module named 'mos.settings.secret_key'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "manage.py", line 17, in <module>
    execute_from_command_line(sys.argv)
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
    utility.execute()
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/core/management/__init__.py", line 330, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/core/management/__init__.py", line 182, in fetch_command
    settings.INSTALLED_APPS
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/conf/__init__.py", line 48, in __getattr__
    self._setup(name)
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/conf/__init__.py", line 44, in _setup
    self._wrapped = Settings(settings_module)
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/conf/__init__.py", line 92, in __init__
    mod = importlib.import_module(self.SETTINGS_MODULE)
  File "/home/mw/src/mos/devel/lib64/python3.5/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 986, in _gcd_import
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 662, in exec_module
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "/home/mw/src/mos/mos/settings/devel.py", line 2, in <module>
    from .common import *
  File "/home/mw/src/mos/mos/settings/common.py", line 12, in <module>
    from django_extensions.management.commands import generate_secret_key
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django_extensions/management/commands/generate_secret_key.py", line 5, in <module>
    from django_extensions.compat import CompatibilityBaseCommand as BaseCommand
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django_extensions/compat.py", line 33, in <module>
    from django.contrib.auth import get_user_model
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/contrib/auth/__init__.py", line 7, in <module>
    from django.middleware.csrf import rotate_token
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/middleware/csrf.py", line 14, in <module>
    from django.utils.cache import patch_vary_headers
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/utils/cache.py", line 26, in <module>
    from django.core.cache import caches
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/core/cache/__init__.py", line 34, in <module>
    if DEFAULT_CACHE_ALIAS not in settings.CACHES:
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/conf/__init__.py", line 48, in __getattr__
    self._setup(name)
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/conf/__init__.py", line 44, in _setup
    self._wrapped = Settings(settings_module)
  File "/home/mw/src/mos/devel/lib/python3.5/site-packages/django/conf/__init__.py", line 113, in __init__
    raise ImproperlyConfigured("The SECRET_KEY setting must not be empty.")
django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty.

Any ideas how to solve this?

As a result, ansible fails because it assumes a superuser account with ID 1.

We worked around it by manually creating a superuser account in the half-finished VM via ./manage.py createsuperuser and then re-running vagrant up --provision

Enter a Wiki Page with Spaces in the title.
MediaWiki does replace them with underscores.
iCal Export cuts off at the first space instead of replacing them with underscores.
This results in URLs in the iCal exported events that point to a defunct or a totally different wiki page.

This is triggered when mailing the full list of members (currently around 200).

A quick workaround is to configure gunicorn with --timeout 120, but ultimately this should be handled with a StreamingHttpResponse.

It seems that the last membership period is considered instead of the first. Maybe the info page should display User.date_joined anyway?

Via. sonstwer
Wenn man auf
​https://metalab.at/calendar/
ein Event hinzufügt gibt es die Auswahlmöglichkeit
Lounge (Raucherbetrieb) +
Lounge (Nichtraucherbetrieb)

die sollten gemerged werden, ich weiß halt nicht wie.

Enabling logging causes Django to dump a whole lot of %(message)s log statements, without providing an actual message. Find out why.

I just tried to install a test instance of mos on my local Debian 7 machine.

Steps 1-4 are working just fine.
But this one fails:
5. Install dependencies: pip install -r requirements.txt

Log:
pip.log