{% extends "base.html" %} {% load static from staticfiles %} {% block headers %} {% endblock %} {% block title %} {% if not user.is_authenticated %}

Welcome to {{ HOUSE }}

{{ HOUSE }}


{% endif %} {% endblock %} {% block content %}
{% if user.is_authenticated %}

Contents


  1. Welcome
  2. {% if user.is_superuser %}
  3. Admin: Managing Users
    1. Adding Users
    2. Modifying Users
    3. Profile Requests
  4. Admin: Miscellaneous
    1. Anonymous User
    2. Model Recounts
    3. Django Admin
  5. {% endif %} {% if user.is_superuser or PRESIDENT %}
  6. President: Meta-Manager
    1. Adding Managers
    2. Managing Managers
  7. President: Request Types
    1. About Request Types
    2. Adding Request Types
    3. Managing Request Types
  8. {% endif %}
  9. Navigation
  10. General Tips
  11. Profile Management
    1. Profile Details
    2. Password
    3. Profile History
  12. Threads
    1. Starting Threads
    2. Adding Messages
  13. Requests
    1. About Requests
    2. Working with Requests
  14. Announcements
  15. Events
  16. Miscellaneous
    1. TinyMCE
    2. Date-Time Picker
    3. Search

§ Welcome to {{ HOUSE }}

{% else %}
{% endif %}

Welcome! This is a virtual gathering place for members of {{ HOUSE }} as well as a community outreach and general information site.

{% if not user.is_authenticated %}

If you are a new member, you can request an account by clicking here or on the request profile link in the menu above. Once your request is submitted, an admin will contact you.

{% else %}

This help page is quite lengthy and tries to be as exhaustive as possible about how to use this website. If you find that this page is lacking in information or clarity, please feel free to contact Karandeep. Or better yet, you can open up the source code and update this page yourself.

For quick links, please refer to the table of contents.

{% endif %}

This website is an instance of a project called Farnsworth, planned and executed by Karandeep Singh Nagra and Nader Morshed. It was originally developed to encourage the use of new technologies in the Berkeley Student Cooperative and provide a better online presence for houses in the cooperative. The site is designed abstractly and easily set up for any other house with a few settings changes. Several example implementations of Farnsworth exist for you to mimic. If you would like to implement an instance of Farnsworth for another house, please contact Karandeep at karandeepsnagra@gmail.com.

Farnsworth is free and open source software. The source code is freely available in this GitHub repository. You are encouraged to modify, expand, and share this software with others. The several branches of this repository represent different implementations of Farnsworth for different houses. If you would like to contribute to this project, see the roadmap for a list of features you can implement. Pull requests to the repository are welcomed.

{% if user.is_authenticated %} {% if user.is_superuser %}

§ Admin: Managing Users


§ Adding Users

You can add a user from the add user page. Usernames should be unique and a single word composed of alphanumeric characters or the underscore character. It is recommended that e-mails and phone numbers be kept hidden from other members when creating a user. A user can modify her/his own profile to reveal e-mail and phone number to other members.

The "is active" status is an indicator of whether the user can login. You can add inactive users, but you will probably be adding active users. Starting alumni as inactive users is advised, as this will result in a tighter security spec for your implementation of Farnsworth. Doing so is permissible as alumni are not very likely to log in. And if an alumnus does want to, s/he can e-mail you (via the e-mail listed at the bottom of this page to get her/his account activated. When an inactive user attempts to login, s/he is given a message saying her/his account is inactive.

The "is staff" status indicates whether a user can access the Django admin pages. Use of the Django admin pages is discouraged. If something really needs to be done at that level, it would be better if you wrote the page up yourself in the regular interface and shared it with everyone else using Farnsworth. Writing pages is very easy. Read the documentation at Karandeep's GitHub repo or contact him directly (e-mail: karandeepsnagra@gmail.com) for some quick tips.

However, even if a user has staff status, s/he will not have any privileges without a superuser giving her/him those rights. This can be done from the Django admin pages. Read the Django docs to learn more.

The "is superuser" status toggles admin rights on the site. A user with superuser privileges will able to access admin pages written into this interface and have full privileges in the Django admin.

It can be useful to give users superadmin status and not give them staff status as all admin privileges in the custom admin are granted with superadmin status, but access to the Django admin is restricted. Effectively, superuser-not-staff status is a weak obfuscation-based security against users really messing things up by misusing the Django admin.

Groups are fully supported by Django but are not yet supported by the custom Farnsworth interface. They are provided in this page in case someone wants to do further development of Django which involves groups. You can CTRL-click and select multiple groups from this list.

You must provide a password. An option is not yet available to create users without passwords. This would be a neat feature if you care to implement it yourself. If you want to create a user that will probably not use the site for a while (alumni, for example), it is recommended that you toggle off the "is active" option for the user. You can toggle it back on later by modifying the user when the user wants access to the site.

§ Modifying Users

A list of all users can be seen at the manage users page. This page will give you a quick run-down of users, their e-mail addresses, phone numbers, and active, staff and superuser statuses. The tables are sortable. You can click on any heading to sort the table by that column. You can also hold Shift and click multiple column headings to sort by all those columns successively. By default, the tables are sorted by last name and then first name. Clicking on an e-mail address will prompt you to send an e-mail to that address. You can click on any user's name from the manage users page to edit that user's profile.

From the modify user page, you can change a user's personal details, member status, etc., as well as change her/his password. To prevent permanent lockout, if you are the only superadmin, you will be prevented from changing your own superadmin status. Everything else will be saved when you try to change your own profile as the only admin.

It is highly recommended that users not be deleted. You should instead deactivate them. But if you really need to delete a user, you can do so from the modify user page for that user. Doing so will delete all threads and requests the user posted, all messages and responses the user posted, as well as all events and all announcements the user posted. This can mess up all manner of things. So it's recommended that you not do it.

You will be required to provide your password to delete a user.

To prevent someone from maliciously changing your password if you leave yourself logged in somewhere, you are prevented from changing your own password from the modify user page. You can instead change your password from the my profile page.

You cannot modify usernames from the custom admin pages, but you can do so from the Django admin pages. It doesn't seem productive to allow such a change as the user who owns the account will locked out of his/her account and unable even to know what happened.

You are also discouraged from modifying the anonymous user (username "{{ ANONYMOUS_USERNAME }}"). When you open this user's edit page, a warning will be displayed saying the same. More on the anonymous user is covered under the Anonymous User sub-section of the Admin: Miscellaneous section.

On every user profile page (a general user page accessed from various parts of the site, most notably the member directory), there will appear a yellow edit button in the top right corner if an admin is accessing the page. This button does not appear for non-superadmin users; so you don't need to worry about that. Clicking this button will redirect you to the modify user page (an admin page accessed usually through the manage users page).

The modify user page is almost identical to the add user page, with a few exceptions. First, the username, first name, and last name fields are missing. And second, there is a separate form at the bottom to change the password. You can update the profile or change the password for the user, but not both in one HTTP request. AJAX is not currently supported. This is another cool feature, if you care to implement it.

§ Profile Requests

Sometimes - especially at the beginning of the semester - you will get requests for new profiles. These can be managed from the manage profile requests page. Profile requests contain most of the information affiliated with a prospective user profile. You can sort this table as well, in the same way described in the Modifying Users sub-section above. You can click on the e-mail link to write an e-mail to the user or click the user's proposed username to modify the request.

The form in the modify profile request page is almost identical to the one in the add user page (detailed above), with a few exceptions. First, the information the user provided in her/his profile request is used to fill some of the fields of the form. Second, there is a button next to the add user button that allows you to delete the request permanently. And third, there is no password field since the user provided her/his own password when submitting the request.

Please note that if a request is deleted, there is no way to retrieve it. The user will have to fill another request, or you can add the user manually (check the adding users section above for more info).

§ Admin: Miscellaneous


§ Anonymous User

Farnsworth comes prepackaged with an anonymous user. This user (and profile) is autogenerated the first time you start an anonymous session. The default username is {{ ANONYMOUS_USERNAME }}. This can be changed from the settings file (/path/to/head/farnsworth/settings.py) before starting a first anonymous session. Don't change this setting if the anonymous user already exists. The autogenerated user is named Anonymous Coward. This is a bit trickier to change; contact Karandeep if you really want to change this.

The anonymous user is intended for logins on common space machines. Since users will want access to the site fairly quickly on common space machines and won't want to login and logout constantly to check minor things, the anonymous user can be used to fill the need. The anonymous user is prevented from up/down voting requests or RSVP-ing to events. But the account is permitted to start threads, post messages, make requests, post responses, and start events.

An anonymous session is started from the utilities page. Login on a common space machine and go to this page and start an anonymous session. When the anonymous user is logged in, the profile links are disabled and replaced by a login link. Users can temporarily login to assume identity. When a logged in user logs out, the anonymous user will be logged in and the anonymous session will resume. Anonymous sessions are easy to detect as the login/profile link (the second link in the menu) is red during an anonymous session.

Logout is disabled for the anonymous user. To logout the anonymous user and end the anonymous session, login as yourself in the anonymous session, go to the utilities page, and end the anonymous session. This will logout the anonymous user and end the anonymous session. Your session will resume. So make sure to logout yourself if you intend to leave the computer.

The anonymous user is also forbidden from modifying the anonymous user profile. An error message will be displayed if a user tries to modify the anonymous user profile from the my profile page. The member directory excludes the anonymous user and the profile for the anonymous user

§ Model Recounts

To save processor power and increase efficiency, Farnsworth counts thread messages and request responses very infrequently. These fields are incremented whenever a new message or response is posted. However, if messages or responses are deleted (only through the Django admin interface), or users or user profiles are deleted (also only through the Django admin interface), these fields can fall out of sync. The fact that this can happen is one of the reasons you are discouraged from using the Django admin interface. To further the development of Farnsworth, you are encouraged to write your own interface for doing things not currently supported.

To correct for the possibility of the database entries for response and messages counts, a utitility is provided to recount these fields. The recount utility is accessed from the utilities page. When you recount responses and messages, Farnsworth iterates over the set of requests, checks if the number of responses in the database is different from the number present in the model instance of each request, and if it is different, Farnsworth changes the model field of the request to reflect the newly counted number of responses. Thread messages are counted in an identical fashion.

Since UPDATEs are heavier, resource-wise, than SELECTs, in database systems, this setup is more efficient than recounting responses or messages for and changing every instance of request and thread, since it reduces the number of UPDATEs while maintaining the number of SELECTs.

Even still, the recount process may still take a while. Avoid having to use this utility by not messing with the Django admin interface often.

§ Django Admin

If you absolutely must use the Django admin interface, here are a few quick tips on how to use it.

Django arranges its admin interface by application. There are several applications that make up the whole of Farnsworth. These include an application for threads, an application for requests and announcements, and an application for events. You can click on the header of each of the tables to see just that application or select one of the model types listed. By selecting one of the listed model types, you can get a list of all model instances of that type. Then you can delete or modify these models.

Certain fields have been disabled for models. You can change this aspect of the program with some effort. If you haven't worked with Django before, contact Karandeep for more details on how to do this.

There are also links form these pages to add new instances of models. You can use these to manually create models, though this is not a very likely scenario.

The Django auth application is used for handling user authentication. The auth package includes a user model and a group model. The user model contains the core set of fields for users on this site. But to augment this set, a user profile model with a one-to-one relationship was created in the threads application. This decision was made to make it easy to integrate Farnsworth with other Django applications or with other interfaces that are Django-compatible.

Note that deleting a user will delete all model instances dependent on that user instance. This means that all threads (including mesages associated with a thread started by the user), all messages, all requests (including all responses associated with a request posted by the user), etc. are deleted when a user is deleted. Do this only if you really really really need to delete a user. You will be prompted with the repercussions of deleting a model when you try to delete any model at all from the Django interface.

For most cases, though, simply deactivating users is sufficient and encouraged.

Django fully supports groups and permissions in case you ever need to implement a system that needs either or both of those features. For example, you can group users together by semester and then create a custom filter for the member directory or manage users page to see only users who are in that semester group. This feature is not currently on the roadmap for Farnsworth but would be a useful feature for the future, especially as the number of users grows linearly every semester.

Managing all models is identical through the Django admin interface. Please refer to Django's documentation for more on how to use the admin interface to manage model instances.

{% endif %} {% if user.is_superuser or PRESIDENT %}

§ President: Meta-Manager


§ Adding Managers

Managers are managed from the meta-manager page.

You can add a new manager by clicking the top right button on the meta-manager page or by going directly to the add manager page. A manager position can have only one incumbent. Keep this in mind.

Since houses allow multiple members to hold the same position, an "active" status is available for these scenarios. The recommended way to have multiple members hold the same position is to create multiple types of a singular position. So, for example, to have a Kitchen Manager position that can have more than one incumbent, create two (or three or four, depending on your house) instances of Kitchen Managers (Kitchen Manager 1, Kitchen Manager 2, ...) and then deactive the excess manager positions.

Though this may seem a shortcoming of the site, in practical terms, it's a decision between a clean end-user experience and a clean site admin experience. Having multiple incumbents for the same position makes sorting and searching more cumbersome for the user. A simple injective relation is optimal for understanding managers and incumbents.

Yes, this implementation does mean slightly more work for you. But it means significantly less combined mental work for end-users.

All fields in the form to add a new manager are optional except the manager title field. Farnsworth auto-generates the URL key for the manager from the title you provide by lower-casing all letters, replacing spaces with underscore, and a few other things that are covered in the documentation. "Kitchen Manager 1" → "kitchen_manager_1", "WRM" → "wrm", etc. These URLs are used to reference managers in the directory and the meta-manager. You will be thrown an error when adding a manager whose URL collides with a previous URL.

The "president" status gives the user rights to do President duties, which currently include managing managers and managing request types. Planned expansion of these duties include managing petitions, elections, and a few other things.

The "workshift manager" status is currently not used but is included in case a workshift package is rolled out in the future.

The "active" status indicates whether the manager is visible in the directory to the general membership

The e-mail form should be for official e-mails for that manager, not personal e-mails. Personal e-mails are under individual users' control. This field is optional as not all manager positions have dedicated e-mail addresses.

If there is a manager position without an e-mail address and the incumbent has set her/his e-mail to be visible to everyone, the incumbent's e-mail will be displayed in the manager directory and in individual manager descriptions, with a short snippet saying that the listed e-mail address is a personal e-mail address.

So you don't need to go get the incumbent's permission and then add her/his e-mail to the manager record, and then delete it again when the incumbent's e-mail or the incumbent herself changes. Besides succinctness, this implementation gives users better control over their own information and its visibility.

The incumbent field is optional and excludes all alumni. Effectively, only residents and boarders can hold manager positions. If an incumbent for the position doesn't exist, leave the option blank (displayed as a series of dashes) and the position will be created without an incumbent.

§ Managing Managers

There is a catch in that when a user is changed from a resident or boarder to an alumnus, s/he continues to be the incumbent for the position. So, some maintenance on the site is required on your part at the beginning and end of each term, or whenever a manager position is vacated/refilled.

For this maintenance work, you will need to modify manager instances.

You can see a list of managers and links to their modification pages, incumbent user profile pages, and manager e-mails from the meta-manager (a manager of managers) page. This list will tell you most of the handy information about each manager, as well. Unlike the manager directory, this list does not show incumbents' personal e-mails. The meta-manager table is sortable, just like any other table in Farnsworth. You can hold down the Shift key and click multiple table headers to sort by all of the ones you select.

When you click on the title of each manager, you will be directed to a page to modify that manager instance. This form is identical to the add manager form; so details will not be covered here. The same conditions apply and the same tests apply when you try to modify a manager as when you add a manager. If you try to change a manager to have the same title as a different existing manager, you will be thrown an error. Similarly, if the URL name resolved from the title you gave collides with the URL of a different existing manager, you will be thrown an error.

§ President: Request Types


§ About Request Types

Farnsworth abstracts manager requests so that request types can be created on the fly as needed. A request type is simple. It has a name, relevant managers, an enabled status, and an optional glyphicon. Names should be unique and resolve to unique URLs. URLs are resolved by lowercasing all letters, replacing space characters with underscores, replacing &'s with "and"s, and removing special characters such as *, $, !, and ?.

A request type's relevant managers are all the managers to whom requests of that type are made. The enabled status controls whether new requests of that type can be made. However, even if a request type is disabled, users will be able to post new responses to requests. Disabling request types can be useful when a manager position has been vacated, managers are being harassed on the site, etc.

When there are no existing or enabled request types, the Requests dropdown menu will disappear. The dropdown menu only appears when there is at least one enabled request type. When request types are enabled, they will automatically be added to the list in the dropdown menu. When request types are disabled, they will automatically be removed from the list.

You can see a list of request types from the manage request types page.

§ Adding Request Types

The Add Request Type button on the manage request types page will take you to the add request type page. Filling out and submitting this form will add a new request type.

It is recommended, for presentability, that request types be treated as titles (first letter of each word capitalized, unless an acronym). Request type names are converted to URLs in the same manner as the manager titles; so the same rules apply to request type names as manager titles.

Glyphicons are optional. If you leave the field blank, the default icon (the inbox icon used for the Requests dropdown menu) will be used for the request type. If you mistype the glyphicon, however, no icon will be displayed. There is a link in the form (which opens in a new tab) to all the currently available glyphicons. You can use any of them, but it might be better to steer clear of a few key ones used elsewhere in Farnsworth and others that serve as warning symbols.

Here is a list of some of the glyphicons and their recommended use:

  • Food: cutlery -
  • Maintenance: wrench -
  • Health: heart - or heart-empty -
  • Garden: tree-conifer - or tree-deciduous -
  • Social: glass -
  • House Manager: credit-card -
  • Site: globe -
  • Network: signal -
  • Supplies: shopping-cart -
  • Geek Social: film -
  • Waste Reduction: trash -
  • Historian: camera -

There is no hard limitation preventing you from using the same glyphicon for multiple request types, but it will greatly enhance user experience if you use glyphicons intelligently.

When users access this site from a small screen (smart phones, etc. < 768px in width), text from certain buttons is not displayed, and only the glyphicon in those buttons is displayed. In these cases, it can help to have an intuitive glyphicon for users to know what request type they are accessing, to which page they are navigating, etc. Also in these cases, it is especially crucial to type the glyphicon correctly as the buttons will be empty (since there is no glyphicon) if the glyphicon is mistyped.

§ Managing Request Types

You can see a list of all the request types with links to modify them, relevant managers, and whether they are enabled from the manage request types page. From here, you can also see links to view relevant managers or their incumbents. When you click on the name of a request type, you will be taken to the modify request type page.

This form is identical to the add request type page.

{% endif %}

§ General Tips


All tables in Farnsworth are sortable. If you click on the header of a table, you will sort by the items in that column. You can hold down Shift and click multiple column headers to sort by each one successively.

Be careful of what you post on the site. If you post something on the site, it is a tedious process for the admin to delete your post. Admins may refuse to do so since the process can sometimes be dangerous to database integrity. Admins are discouraged from deleting posts in Farnsworth's documentation due to this risk.

The site collapses to a mobile version when the screen size reduces down to an extra small size (< 768px in width) or if the site is launched with a small screen size. Several things happen dynamically:

  • Font size in container headers (colored horizontal bars at top of containers) changes as screen size changes.
  • Text from container header buttons disappears when the screen gets to the extra small size.
  • Certain text elements are replaced by others upon screen size change.
  • Certain images and maps are replaced by others or disappear entirely when the screen is extra small.
  • Some containers rearrange themselves depending on the site of the screen. Some containers will be side-by-side on larger screens but one-above-the-other on smaller screens.

Learning to use the site is done best on large screens, as the mobile version is essentially reduced in visual aids, such as the text in container header buttons. Using the mobile version is not cumbersome, still.

The contents of containers will sometimes be too large for containment, especially on extra small screens. In these cases, the overflow contents of containers become horizontally scrollable. On mobile devices, you can tap and drag the contents of a table to scroll horizontally. Try this out on a small smart phone screen with the threads list on the homepage.

The site uses several third-party packages, like TinyMCE, Bootstrap Datetime-Picker, and Django-Haystack. Details on how to use these can be found in the miscellaneous section.

§ Profile Management


§ Profile Details

Control over your profile is handled through the my profile page. You can access this page from anywhere from the top menu. Links to this page are also sprinkled across the website - a link appears anywhere you posted an event, request, thread message, etc.

Please note, you cannot edit your first or last names, but you can request your site admin to do it for you.

By default, your first & last names and username are visible to all users, but your e-mail and phone number are only visible to the site admin and no one else.

However, you can allow others to see your e-mail address and phone number by toggling the e-mail visible and phone visible checkboxes in the update profile container. Doing so will display your phone and e-mail in the member directory and in your profile. Your e-mail will also become searchable when it is made visible; so that others can search for your profile by your e-mail.

Enabling phone visible will also display your phone number in the manager directory and the manager details for all manager positions you hold. Enabling e-mail visible will display your e-mail if a manager e-mail does not exist for a position you hold.

The current room, former rooms, and other houses fields are also indexed for search, meaning people can find you by your room or affiliation with other houses if you input this information.

Whenever you remove information, it is removed from the indexes. So if you later decide that you don't people to be able to search for you by a particular field, you can erase the field.

§ Password

You can change your password from the same page using the change password form at the bottom.

For your security, your password is hashed before storage. Hashing is a function that takes a regular value converts it to a value that is impossible to decrypt back to its original value using the current technology. Hashing makes your passwords safe and it's commonly done throughout the IT industry.

This means that admins cannot see your password. You and only you should know your own password. However, if you ever forget or lose your password, an admin can reset it for you.

§ Profile History

You can see some parts of your profile history from the profile dropdown menu items in the top navbar. These include links to see all your requests and all the threads you have started. You cannot see all the messages you have posted, but you can search for threads you have posted to or search for the thread subject itself.

There are two views each of these two types of pages, but the ones that are linked in the menu are the concise ones. These will simply list your requests or threads with meta-data and some core details about them. The expanded views can be slow to load, but you ca load them from the simple views using the buttons in the container headers.

§ Threads


§ Starting Threads

Threads in Farnsworth are designed like e-mail threads in most ways. You can start threads from various pages, including the homepage and the member forums page. The form is identical from any page. Both the subject and the body of the form are required. The subject will constitute a title for the thread and the body will constitute the first message in the thread.

After you have started a thread, anyone can add a message to that thread. Messages in threads are sorted by date. The old message (the one used to start the thread) is always listed first, and the most recent message is always listed last.

Threads are not deactivated and can be "revived" by simply posting another message in the thread. For reference, the homepage grabs the most recently modified threads to list. So if you add another message to a really old thread, it will be pushed to the top of the list on the homepage, grabbing attention for the thread from the entire membership.

§ Adding Messages

You can add a message to a thread from a view with the thread. Generally this will be from the member forums or the thread view page. Messages require only a body and are fully editable and just like the body of a new thread.

New messages are added to the end of a thread and displayed below all prior messages. Threads are therefore designed completely linearly, rather than as trees - how some forums on the Internet are designed.

For the growth and spread of discussions, you are encouraged to branch threads by creating new ones similar subjects to steer the discussion is a different direction or to focus in on a specific issue in the parent discussion.

Doing so will keep threads clear and concise while allowing for full discussion.

§ Requests


§ About Requests

If your House President adds and enables request types, you will see a requests dropdown menu appear in the navigation bar. From here, you can select a request type and add requests of that type for managers to address.

Each request type has a list of relevant managers. Active relevant managers and their incumbents will be displayed whenever you visit a request page. For example, for food requests, the relevant manager might be your Kitchen Manager or Food Manager or multiple Food Managers or Kitchen Managers.

When a relevant manager posts a response to a request, the body of the reponse will be colored a light blue and have hover text indicating that the response is a manager response.

Relevant managers also have the ability to mark requests closed or filled. A filled request will have a light green body and a closed request will have a light red body. Hovering over the body of a request will display hover text indicating the request's status (open, filled, or closed).

Requests also keep a running record of up votes. All user up votes are recorded and the number tabulated upon display of requests.

§ Working with Requests

You can add a new request of a certain request type from that request type's request page. Requests contain just a body that is fully editable like the body of a thread or message.

After you have posted your request, you or anyone else can add a response to the request. Others can also up vote your request to express support for your request. If you up vote a request, you can cancel your up vote by clicking the cancel up vote link.

The vote count will be displayed next to the name of the person who originally posted the request. Clicking on this count will display a dropdown menu containing a list of up votes for that request. You can click on any of these names to see the up voter's profile.

§ Announcements


If you are a manager, you can make an announcement that will be pinned to the home page and the manager announcements page until you unpin it. If you unpin an announcement and want it to be repinned, you can visit the all announcements page to repin it to the home page and the manager announcement page.

Announcements are meant to be high priority addresses to the entire house. You can use announcements to warn the house about emergencies or provide critial information.

Once you have posted an announcement, it will automatically be pinned to the home page and the manager announcement page. You can unpin the announcement by clicking the unpin link at the bottom right side of the announcement. Doing so will move your announcement to the archives, where it can still be seen.

If you accidentally unpin an announcement and want to repin it, you can go to the all announcements page and repin it from there.

You can edit an announcement by clicking the edit link at the bottom right side of the announcement. Once you edit an announcement and save it, you will be taken to a page that shows you the modified version of the announcement. From here, if you approve, you can navigate anywhere else. Your announcement is already updated and saved. If you disapprove, you can click edit again and modify the announcement again.

You cannot modify the announcement of a previous incumbent for a position you hold. However, you can copy paste it and start a new announcement. You can also ask the site admin to modify it or unpin/repin the announcement for you.

§ Events


Events can be posted from the upcoming events page or the all events page. All fields except the RSVP and Mark Cancelled checkboxes are required in this form. By default, {{ HOUSE }} will set as the location of the event and the RSVP box will be checked.

For picking the date and time of the event, Farnsworth uses Bootstrap Date Time picker, details on which can be found in the Date-Time Picker sub-section of the Miscellaneous section.

Once you're posted an event, others can RSVP to it. The list of RSVPs will be displayed with every event. You are by default RSVP'd to the event you posted. You can un-RSVP to the event by clicking the Un-RSVP link at the bottom right of the event.

If you need to edit the event, you can do so by clicking the edit link at the bottom right of the event. Once you've modified and saved your event, you will be taken to a view of that event. Your event already updated and saved. You can edit it again or navigate anywhere you'd like.

§ Miscellaneous


§ TinyMCE

Farnsworth includes a "what you see is what you get" (WYSIWYG) editor called TinyMCE used in several places in the site. TinyMCE is feature rich and does extensive security checks on its own. TinyMCE allows image and video inserts via iframes or URL links. Both of these methods can be used through the buttons in the TinyMCE interface.

Using URLs is the more straightforward and approachable way to insert videos. TinyMCE will do the work for you in finding the video from the URL you enter and inserting it into your message. This may not work properly sometimes (e.g., when more than one video is on a page).

In these cases, you can use the iframe option, which is slightly more work. You will have to get the iframe code from the video you are trying to insert and then paste the code into the text field in the "Embed" tab of the insert/edit video popup of TinyMCE.

TinyMCE also supports inserting emoticons, special characters, links, ordered & unordered lists, and horizontal rules. These can all be accessed from the buttons in the interface.

Formatting can be done via keyboard as well as the buttons in the interface. For example, you can press CTRL + B to bold, CTRL + I to italicize, or CTRL + U to underline text. The buttons available will allow you greater control over your formatting. You can insert headings, change font size or font, strikethrough text - like this - and insert text to be rendered as code - like so:

python hello_world.py

TinyMCE also supports inline code, like so: print "Hello, world!", divs, paragraphs, and blockquotes:

Cogito ergo sum.

These options can be selected from the blocks sub-menu in the formats dropdown menu inside TinyMCE.

TinyMCE also supports keyboard shortcuts to copy (CTRL + C), cut (CTRL + X), or paste (CTRL + P) text from or to the text field, along with several other keyboard shortcuts.

However, please note that TinyMCE will preserve the formatting of text you paste into the editor, including background color. So, it is recommended that you paste input as plain text, an option offered by TinyMCE. You can click the paste as plaintext button, which render anything you paste as plaintext until you toggle the plaintext button to off.

You can also align your text however you please and undo/redo your changes.

However, a downside of using TinyMCE is that your input will not be preserved between attempts to submit forms. So it is crucial that you input all required fields to ensure that the form is submitted on the first try.

§ Date-Time Picker

Bootstrap Datetime Picker is used in Farnsworth to pick date and time for events. It allows the selection of a date and then a time from a box that drops down when a datetime field is clicked. The widget allows you to quickly move through dates through several means.

You can click on the arrows at the top of the dropdown calendar to flip through the months. If you click on the month year field between the arrows, the widget will swith to a month view, with a year at the top and months listed below. From here, if you click the arrows, you can quickly flip through years, or you can click the year field, which will switch the widget to a year view. From here, you can quickly flip through decades via the arrows at the top.

If you click the clock icon at the bottom of the calendar, the widget will switch to a time view. From here you can select a time, in hours, minutes, and AM/PM. To switch back to the calendar view, click the calendar icon at the top of the widget. If you click on the hour button, the widget will switch to an hour selector, form where you can select an hour. If you click the minute button, the widget will switch to a minute selector, allowing you to select a minute field in 3 minutes increments.

§ Search

Farnsworth uses Django-Haystack for search. Haystack serves as a wrapper around an engine of your setup's choosing. Most likely, your version of Farnsworth was deployed with Elasticsearch, an implementation of Lucene, a pure Java search engine.

You can search the entire site from any page via the search bar in the navigation bar. The indexes are updated live; so results should always be up to date.

Farnsworth's implementation is designed to use partial-word search. You can search for parts of a word and get effective results. Haystack matches 2-letter combinations for parts of the words you type with parts of all words in the database.

As a drawback to this implementation, you will often get results you aren't looking for. But most likely, if you are specific with your search, you will get results you are looking for.

Search results can be filtered by clicking the filter button at the top and selecting one of the filter choices, if any.

Results are paginated for presentability. Undoubtedly, as the database grows larger, more results will be returned. So, you can click through the pages at the bottom to look through the results for your query.

{% endif %} {% endblock %} {% block endscripts %} {% endblock %}