Skip to content

(Looking for developers) Guest list feature requirements

Jump to bottom Edit New page
Maxim Drachinskiy edited this page Jan 22, 2018 · 1 revision

Project description

Overview

Your task is to develop a module that extends events functionality by adding Guest Lists / Attendance Lists: in addition to existing event information and schedule, an event should show a list of people attending the event and provide authorised users with an option to tick/untick people or add/remove names.

Requested features

  • A Guest List is a list of persons invited to an event, usually external guests at a party - similar to a guest list on Facebook events. An Attendance List is a list of club members attending a meeting, usually CV participation. Both list types should share the same code base in the backend, but differ in representation: basically, a guest list is a smaller version of a fully-featured attendance list, with some features turned off.

  • The lists should have the sorting/filtering functions (e.g. when did the person come, show unticked users only, ...)

  • Next to or under the list a few statistics would be nice, e.g. attendance list: how many members have attended, is this number > half so we can start elections, etc. Additionally, some individual highlights would be nice, e.g. a member did not attend three CVs in a row.

  • For a guest list we need a facebook guestlist import function, e.g. input an event URL - get the list populated with names.

  • For attendance lists it should be possible to automatically add all active club members/candidates/etc.

  • Three options are required: "was there", "was not there", "excused".

  • (Optional) Logged in members should be able to change their own status (on an attendance list) to "excused" with a button, but only before the event begins. During Attendance List creation, each member with a status "on vacation" should automatically be entered as "excused".

  • Each entry in a Guest List / Attendance List should have an (optional) comment field, e.g. for notes like "+1" or "+ Max Mustermann" etc. (Similar to comments on normal shifts.)

  • Changelog: every change on the list should be logged (timestamp, who made the change, etc.). Additionally, a changelog should be available on the event page, visible to club members, also updated in real time if possible.

  • Furthermore, a table-styled Summary of multiple attendance lists should be provided. Its purpose is to track CV attendance in a chosen time period (usually current month), see screenshot attached. Users should be able to choose arbitrary dates and get a table-styled view of all attendance lists in that period as columns, all active members (or manually added names) as rows, cells showing if this person attended that event. Same filters and statistics as for individual Attendance Lists should apply.

  • Both guest and attendance lists should have an option to allow editing/(un)ticking names only possible when a "change-password" is provided (except password is empty, which means anyone can edit). Users from the groups "Clubleitung" and "Admin" should be able to edit any list without knowing the password (including password change).

  • People organizing the event should be able to get a link that allows people to register until a certain deadline, by entering their data and a "add-password" for the list.

  • Guest / Attendance List and Attendance Summary should include a print version.

  • All added views should include a German and an English version.

  • All added views should have a desktop, a tablet and a mobile version, containing full functionality on any device screen size.

  • Event creation and editing pages should be extended with a section allowing to append a guest list or an attendance list to this event (or none) and to fill it with names.

  • Main event view should be extended with two tabs, first showing event schedule (shifts and members doing them) and second being a guest or an attendance list.

  • The exchange with the server (e.g. (un)ticking a person from a guest list at the entrance) should happen in real-time (AJAX-based).

  • We develop for Laravel Version 5.4.

  • We develop for modern browsers only: code should be tested in the latest versions of Firefox, Chrome and Safari, both desktop and mobile versions. Testing mobile versions on respective devices is a plus, but not required - an emulated environment (e.g. built-in browser developer tools) is sufficient. Compatibility to older versions or other browsers (e.g. Internet Explorer) is a plus, but not a requirement.

  • For UX/UI elements, Bootswatch Paper elements should be used (except there is a reason not to).

  • Software project team should actively maintain compatibility to main Lara version and include in their project all upcoming changes made in the main production branch master.

Language

To allow contributors who don't know German well enough to participate in the development process the following rules apply:

  • All comments within the code must be written in English.
  • All variable and function names must be in English.
  • All commit messages must be in English.
  • Issues, pull requests and bug reports should ideally be written in English, but German is acceptable. Important parts might be translated to English later.
  • Answers to issues / pull requests can be either in English or in German - whatever is more convenient for the participants.

Coding standards

Try to get your code as close as possible to the following Coding Style Guides:

Add a custom footer
Add a custom sidebar
Clone this wiki locally