As services like Google calendar don't support any auth-schemes protected / private schedules will need a secret ical url to enable
gcal import.

For this extension I propose using ////<sha_sum>/
as the url. Where the {{{sha_sum = sha256(settings.SECRET_KEY + slug)}}}

This ticket only makes sense after login protected / private schedules have been implemented.

[source:trunk/plan/common/utils.py] is a prime candidate for reorganization into a sperate app.

Currently [source:trunk/plan/templates/courses.html] has some conditional comments to ensure that this form functions correctly in IE6. IE6 will all ways send both buttons and set the value of the sent in data to ''innerHTML'' instead of ''value''. IE7 only has trouble with ''value'', luckily this is not a problem when buttons are used correctly.

Fixing this bug is a matter of adding warning for IE6 users and removing the conditional button hack.

Add a NULLable foreign key from student to users. When this key is set the schedule is considered protected.

Only user who can authenticate as the correct user for the locked schedule can edit it. If view access should be equally restricted needs to be decided.

Users should '''only''' be allowed to lock schedules where {{{ username == slug }}}, this should save us the trouble of having to solve disputes over schedule names.

Traceback (most recent call last):
File "./manage.py", line 15, in
execute_manager(settings)
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/core/management/init.py", line 361, in execute_manager
utility.execute()
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/core/management/init.py", line 306, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/core/management/base.py", line 192, in run_from_argv
self.execute(_args, *_options.dict)
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/core/management/base.py", line 219, in execute
output = self.handle(_args, *_options)
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/db/transaction.py", line 263, in _commit_manually
return func(_args, *_kw)
File "../plan/scrape/management/commands/exams.py", line 56, in handle
if to_delete:
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/db/models/query.py", line 204, in nonzero
iter(self).next()
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/db/models/query.py", line 198, in _result_iter
self._fill_cache()
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/db/models/query.py", line 632, in _fill_cache
self._result_cache.append(self._iter.next())
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/db/models/query.py", line 288, in iterator
for row in self.query.results_iter():
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/db/models/sql/query.py", line 205, in results_iter
for rows in self.execute_sql(MULTI):
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/db/models/sql/query.py", line 1820, in execute_sql
cursor.execute(sql, params)
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/db/backends/util.py", line 19, in execute
return self.cursor.execute(sql, params)
File "/home/adamcik/dev/plan/env/lib/python2.5/site-packages/django/db/backends/sqlite3/base.py", line 170, in execute
return Database.Cursor.execute(self, query, params)
sqlite3.OperationalError: too many SQL variables

I am unable to add subjects that start with IMT*
For example: IMT4115, IMT4113, IMT4110
They are scheduled:
http://www.ntnu.no/studier/emner/IMT4110#tab=timeplan

Error description:
Couldn't add one or more courses
Adding the following courses failed:
IMT4110
Back to your schedule.

Add done timestamp in deadline and allow user to set tasks as done with a simple checkbox.

Got this message from NTNU IT:

God dag.

Iløpet av november - desember blir Syllabus oppgradert til ny versjon. I den forbindelse
vil tenestelaget slutte å levere timeplandata og TIA vil overta leveransane.

Har du fortsatt kontakt med Thomas Adamcik slik at han kan bli varsla?

Tusen takk og ha ei fin helg.

Mvh.

Trond.

Trond Kandal

This info is probably not of much interest for an average user, so a /stats or /about page probably makes more sense.

{{{
for student in semester.student_set.all():
clear_cache(semester, student.slug)
}}}

Should probably do the trick :)

By no means an important task, however for whatever reason I feel core is a better name for this app. As a step in this task one should also look at what really should be in a core app. Code that doesn't make it should be put in an appropriate existing app or one should be created (deadlines is a candidate for relocation).

Hi!

Are you available for some paid work to make a few small tweaks, and also implement a JSON api to the timetable generator?

Please contact me at [email protected].

Figure out a way to populate course links reliably as this now needs to be done for each semester.

Furthermore the magical url generating code should probably note be executed at runtime, but instead moved to a management that handels pre-populating urls.

Update stats methods to use aggregates, will require django >= 1.1

Hi!

I'm planning on building an extension to the online-notifier repo (a chrome extension) which would allow you to see an excerpt from your schedule. Would it be possible for you to share the data or build a simple REST API?

Best regards,
Michael

Currently the db and web scrapes have a lot of more or less duplicated code with respect to syncing lecture data. The db version is currently in better shape and does a better job of handling "duplicate" lectures like EDU3077 on Wednesdays during spring 2010. Correct handling of such cases will require distinguishing lectures on rooms and weeks in addition to groups as the db code does today. The web code on the other hand simply dies when it finds a dupe.

To simplify maintenance and fix the dupe handling for both scrapers the db scraper should be rewritten to create a intermediate data-structure like the web scraper all ready does and they should share a common function for handling this data-structure. An added bonus is that this function will actually be testable :-)

Rendering and downloading the huge course list table is insane. View needs pagination.

Throughout the test code, ''$app/tests.py'' and ''$app/tests/*.py'' there are a bunch of FIXMEs that suggest which extra tests need to be implemented.

Remove --web etc. and make which scrape backend to use a setting.

Either something built in as a app with db and/or email. Or an external feedback app of some sorts.

Page title is hard codec to comply with English apostrophe rules.
However, apostrophe isn't used the same in other languages.
Should behave according to user's language setting.

[source:trunk/plan/common/templatetags/title.py]

Switch, test, fix :)

Course.get_stats should be switched to use aggregate from Django ORM.

Currently the site simply caches entire http responses for the sake of simplicity. However with django-compress as part of the current setup this causes problems. New media files can be synced, removing the old ones, while the cached responses still point to the old files.

This can either be fixed by

• Patching django-compress to have a DELETE_OLD_FILES setting
• Invalidating the cache by catching django-compress signals
• By moving towards template block caching, using template tags to populate blocks.
• Moving caching closer to the database objects being retrieved, and redoing the rest of the views work each time.

Personally I'm inclined towards providing a patch upstream or using signals.

Currently all templates live directly in ''/''. Templates should minimum be reorganized to ''/$app/$template''.

When the language selector is used, the cached page (in the wrong language) shows up. Instead, language should be changed right away.

Possible solutions:

• adding languagecode to cache realm
• invalidating cache on language selection

Needs

• Frontpage should only be URL based, realm should fallback to current semester.
• Course query needs to handle GET while caching.
• Schedule should be cachable by URL alone, realm=slug
• List courses is tricky as url can't be used, should not vary by slug.
• Ical should be cacheable by url, but selector order might be tricky, just
  ingore? or add normalisation decorator before cache? realm=slug
• PDF is cacheable by url. realm=slug

Solutions?

• Cache can be middleware caching all GET queries
• Middleware can set realm and ignore in thread locals, allowing cache to be used regularly.
• Custom cache page decorator could be created.

Profiling of the code has shown that most time is spent within [source:trunk/plan/templates/schedule_table.html]. The current version of this code has three nested for loops within the template code, unfortunately for-loops within django-templates are rather slow due the amount of overhead introduced by django's template features.

Currently the performance is not really an issue, so this task is by no means a priority. However if one where to attempt to solve this issue here are a few possible solutions:

• Create a template tag that uses a faster templating system internally, eg. Jinja (alternatively convert all templates to Jinja)
• Only construct the cell using template code, use pure-python for the loops in the table taking special care to escape everything to avoid XSS. This should probably be implemented with a custom templatetag.

The list of all courses has the lovely feature «Add courses to schedule». The button for adding courses has a minor typo, «coures» instead of «courses» :)

The new version introduced a bug, I think.

The linked course IDs in the "Courses" list link to nonexistent pages.
For example one href is set to "http://www.idi.ntnu.no/emner/operativsystemer" when it should be "http://www.idi.ntnu.no/emner/TDT4186".

I think it worked before.

(Great app, thanks!)

A lot of docs for the system where created during the period working for IME, these need to be ported to sphinx and put up on gh-pages.

It seems that some locations don't get hyperlinked, in this case Vembi:
Without hyperlink
With hyperlink

Not quite sure how the links are made, but

"rooms":[{"location":"H3 Datasal 424 Vembi","lydiaCode":"358424","locationAnnotation":" "}]

gives lydiaCode 358424 which in turn I would think is used in the following query:
http://www.ntnu.no/studieinformasjon/rom/?romnr=358424

The result from this query among other things gives this url which should be appropriate as a hyperlink for Vembi:
http://www.ntnu.no/kart/358/424

Unsure as to why the hyperlink is not created. Haven't studied the Plan code enough, but a very wild guess would be that it has something to do with "location" and "name" not being equal?

"location":"H3 Datasal 424 Vembi"

From https://www.ime.ntnu.no/api/schedule/it3105

"name":"Vembi"

From https://www.ime.ntnu.no/api/fdv/rooms/lydiacode:358424

Any thoughts?

Text in javascript files should also be translated.
http://docs.djangoproject.com/en/1.0/topics/i18n/#translations-and-javascript

Fails to refresh. Would be a great feature for osx users. Anyways, kudos for making a great timetable tool.

For #10 to truly make sense locked schedules need to be tied up against existing NTNU-auth systems.

Integrating Feide should be a matter of finding a Python saml package and writing a django-auth-backend around this.

For SSO support http://www.ime.ntnu.no/dokuwiki/plugin/innsida can be used as a starting point.

See http://docs.djangoproject.com/en/1.0//topics/auth/#handling-authorization-in-custom-backends for more information.

''schedule()'' in [source:trunk/plan/common/views.py#L160] is currently by far the largest function in the entire application.

Firstly the code should be split into three parts, ''schedule_common()'', ''schedule'' and ''schedule_advanced''. Common should be called by the other two and return a dictionary with all data that both methods need. ''schedule'' will simply use these directly to return a template response, will advanced will collect some more data and setup some forms before doing the same.

Furthermore which variables get passed to the template should be cleaned up.

The course TDT4137 was not possible to add even though it can be found at ntnu.no for this semester.
http://www.ntnu.no/studier/emner/TDT4137/2014#tab=timeplan

Shouldn't be much of an issue for "regular" exams. Home exams and other variants spanning many days is more tricky.

#47 had me looking into this, but turns out at least some of the data is just plain wrong as there are a bunch of buildings at Dragvoll that have been "collapsed" so rooms that are in say building 3 show up in building 1 because building 1-6 are all mapped to building 1...

[source:trunk/plan/common/views.py] should be converted to a model and split into smaller files only containing related code.

Newer code assumes that version is set, as such old entries should be given a dummy value 0 or the actual value from the import db. A south datamigration and sql migration should be written for this.

Courses with a version are handled with a silly fallback mechanism as of today.

Add template tag {% googlcal url %} that produces http://www.google.com/calendar/render?cid=host+url

After adding a course users are presented a select groups page, the usability of this page can probably be improved by adding a ''tag-cloud'' like list of all the groups and linking click events on these buttons to all the checkboxes for the same group.

Firstly there are two types of notifications that need to be handled:

1. Short term notices, eg. "Adding course failed..."
2. Long term notices, eg. "Next semester available..."

Notifications can be targeted against:

• All users
• Users for a given semester
• Users for a given course (courses are linked to semesters)
• Given user
• Given user+semester

Notifications can be have the following types:

• None
• Success
• Notice
• Warning
• Error

Notifications can have a maximum age.

Notifications should be written in markdown.

Notifications should be stored in db and use caching.

Notifications should no rely on cookies or sessions.

Notifications should be available to code and admin.

Notications should solve/replace the following issues:

• Next semester loaded notifcations
• Short term user feedback, form errors etc.
• Common deadlines like cutoff date for signing up for new courses.

Currently cookies are only used to store the name of the last schedule visited via the frontpage. Setting cookies that aren't needed is bad form and can additionally break page caching.

Resolving this issue implies removing the remember my ''username'' functionality.

Updates needed in:
[source:/trunk/plan/common/views.py] and [source:/trunk/plan/templates/start.html]

Currently each lecture is added once per week in the feed. Ical supports using RRULE which let us specify the recurrence rate of an ical event.

Title says it all :-)

Currently the only indexes in this application are those inferred automatically from the model definitions. By analyzing slow queries
on the side and other common data-access patterns one should be able
to determine which extra indexes will provide extra performance.

Add color to subscription objects. This should prevent the color scheme from changing unpredictably when extra courses are added.

Selecting the right color for a new course becomes a mater of removing all used colors and selecting the first unused one. If all the colors have been used we start over with a complete set of colors.

Existing data will need to be upgraded, as we don't want to keep the
legacy code around as a fallback.

This update also paves the way for allowing user defined color-schemes.

A mobile style sheet should probably be created to allow for better zooming and handling of the page on advanced mobile devices like iPhones and Andriods.

To further increase the mobile experience a mobile page that only provides a given days schedule would be a nice step forward. Likewise providing a page with only the course-, lecture-, exam- and deadline-list might be useful. If this last step is taken these screen "boxes" should probably be rewritten to template inclusiontags.

Ensure that migrations are in working order with newest stable version of south.