ChangeRequestHotel(id, participant_id, author_id, date, arrival, departure, seen, settled, final_comment)
Hotel(id, name, address, url, info, num_reservations, glat1, glat2, price_per_night, price_per_night_dz, price_remarks)
HotelFeature(id, tag, description, help_text)
HotelFeatureCR(id, crequ_id, feature_id, notes)
HotelFeaturePart(id, participant_id, feature_id, notes)
Participant(id, user_id, institution, address, country, homepage, password, status, career, arrival, departure, hotel_reservation, hotel_assigned_id, hotel_final, funding_requested_hotel, funding_requested_travel, funding_hotel, funding_hotel_complete, funding_travel, funding_final, sponsor, in_participant_list, accepted, cancelled, time_created, time_lastchanged, added_by_admin, salutation)
SocialEvent(id, tag, title, description, date)
messages to participants
sources: * individual messages from edit_admin page * bulk messages from StandardMessage class
as long as sent==False, they have a preview status (and can be edited & sent/discarded in maintenance mode)
A messages sent from the participant, using the contact page.
ParticipantInvComment(id, author_id, participant_id, text, date)
ParticipantOrgComment(id, title, template, filters, date, active)
StandardMessage(id, sender, slug, subject, template, date, active, preview, filters)
# from http://www.djangosnippets.org/snippets/676/ # fixes by ug
Assemble a django “Q” query filter object from a specification that consists of a possibly-nested list of query filter descriptions. These descriptions themselves specify Django primitive query filters, along with boolean “and”, “or”, and “not” operators. This format can be serialized and deserialized, allowing django queries to be composed client-side and sent across the wire using JSON.
Each filter description is a list. The first element of the list is always the filter operator name. This name is one of either django’s filter operators, “eq” (a synonym for “exact”), or the boolean operators “and”, “or”, and “not”.
Primitive query filters have three elements:
[filteroperator, fieldname, queryarg]
“filteroperator” is a string name like “in”, “range”, “icontains”, etc. “fieldname” is the django field being queried. Any name that django accepts is allowed, including references to fields in foreign keys using the “__” syntax described in the django API reference. “queryarg” is the argument you’d pass to the filter() method in the Django database API.
“and” and “or” query filters are lists that begin with the appropriate operator name, and include subfilters as additional list elements:
[‘or’, [subfilter], ...] [‘and’, [subfilter], ...]
“not” query filters consist of exactly two elements:
[‘not’, [subfilter]]
As a special case, the empty list “[]” or None return all elements.
If field_mapping is specified, the field name provided in the spec is looked up in the field_mapping dictionary. If there’s a match, the result is subsitituted. Otherwise, the field name is used unchanged to form the query. This feature allows client-side programs to use “nice” names that can be mapped to more complex django names. If you decide to use this feature, you’ll probably want to do a similar mapping on the field names being returned to the client.
This function returns a Q object that can be used anywhere you’d like in the django query machinery.
This function raises ValueError in case the query is malformed, or perhaps other errors from the underlying DB code.
Example queries:
[‘and’, [‘contains’, ‘name’, ‘Django’], [‘range’, ‘apps’, [1, 4]]] [‘not’, [‘in’, ‘tags’, [‘colors’, ‘shapes’, ‘animals’]]] [‘or’, [‘eq’, ‘id’, 2], [‘icontains’, ‘city’, ‘Boston’]]