joyvuu-dave/comeals-rails

DEPRECATED Comeals allows cohousing communities to reconcile the cost of common meals.

comeals-rails's Issues

As a user, I want to choose my meal preference when signing up to eat at a meal.

In the meal sign-up checkbox area, there is way to indicate the following options:

Late
Vegetarian

As a user, I would like the app to be self-documenting.

Words like "Bill" (that is counted in cents, haha) and "Multiplier" are confusing to me, and I am a power user.

First, all terminology needs to be self-describing. For example,

• Bill => Cost of meal
• Multiplier => [dropdown] Child or Adult.
  These are just two examples from some of the terminology I saw around the site. I am sure there is more, I would be happy to do an audit.

Second, all options should have tooltips that explain their function. Ideally, clicking on form label text or form control in a mobile environment would cause the tooltips to be shown. Basically, it would be a standard for all form elements to have a description tag (data-desc?) that auto-generates the tooltip.

For example,

<label for="multiplier" data-desc="Children are billed for half the cost of an adult. Children are considered any human age 0-15.">
    Adult / Child?
</label>
<select id="multiplier" data-desc="Children are billed for half the cost of an adult. Children are considered any human age 0-15.">
    <option value="1">Child
    <option value="2" default>Adult
</select>

Something like that.

[NOTE] Font used by the physical Swans CoHousing calendar

http://www.myfonts.com/fonts/adobe/graphite-mm/

I have a copy of this font. I am not sure if it can be turned into a web font. However, it may be able to be used if it is installed locally on the machine we eventually put in the Common House.

This is mostly just an FYI. At some point I would like to integrate the original font into the look&feel.

As a user, when I sign up to cook I would like to automatically be signed up to eat.

Right now if you sign up to cook, you have to go down to the eating form and click yourself in the Eating section. This should be automatically opted in as that is going to be the 99.999999% use case.

Max guests, description not being stored to database when editing a meal as a user or admin.

Fill fields:

Click Update:

See incorrect info:

Info not returned when editing again:

As a user, I would like to set a Close datetime for new signups.

This is actually a field on the paper Meal Form, upper left:

How I would like this to work:

1. Every meal signup is timestamped.
2. Every meal signup is marked "logged-in" or "anonymous" to distinguish sign-ups that were by authenticated users, i.e. trustworthy signups.
3. Cooks may set an option on the meal form, "Signups After Closed Allowed (true / false)."
4. If a user attempts to sign up after close, and it is allowed, they are allowed to do so with the following caveats:
   1. They are shown an error that says, "You are signing up after close. There is no guarantee that you will have a plate."
   2. Their name is rendered with a big red border around it, and the time of their signup (basically, their place on the waiting list).
   3. If the cooks add any extras, Post-Closed Signups are made "official" on a first-come, first-served basis.

As an administrator, I would like the ability to log in as a "Common User" with restricted privileges.

Thoughts on how this would work:

• The Common User (CU) would have access to the calendar view, in other words read access to all public data.
• A user could use the app logged in with the CU to sign up to cook.
• A user could use the CU to sign up to eat.
• A cook could use the CU to enter the bill amount.
• A cook could use the CU to enter the max attendees count.
• A cook could use the CU to enter the Extra attendees count.
• A user could opt-in to have any CU actions taken on their behalf validated by a password check, a key fob check, biometric security, whatever.

Am I missing anything? Any thoughts on this approach?

As a user, I would like to see a detailed view of the current rotation.

The paper calendar has this:

IMHO this could be enhanced by showing not only who has not yet signed up, but the dates when others are signed up. This would be nice for requesting scheduling changes.

No field for entering Cost information on meal form.

As a user, I would like to see a "Sign Up To Cook" button on the Calendar page.

Each date that needs a cook should have a "Sign Up To Cook" button that adds the logged in user as one cook for that meal. A meal is created and that user is added as cook. There would still be the "Sign Up To Cook" button so that a second or third person could sign up to cook.

If no user is logged in or "the generic user" is logged in, a pop-up would appear where you could select the user.

OPTIONAL: There should be an opt-in config setting that makes your user not selectable by the default user. This would allow knowledgeable folks (Craig, Tamao) to prevent themselves from being signed up by other users (it's happened on the paper calendar).

As a user, I would like to have my own user account that is tied to my resident entry.

This is pretty straight-forward.

1. Every resident should have a user account.
2. There should be an Anonymous account that can be used in a communal setting that will enable the password-averse to manage the calendar (specifically, "Sign Up to Cook" and "Sign Up to Eat".
3. Users should be able to opt out of allowing the Anonymous account to do anything with their user.

We may want to tie this system into a central login database (LDAP?) if we wind up doing other apps like a laundry app.

As a user, I would like to be able to use this system without having to enter a password. (The Sandra Clause)

To preserve the current status quo, this system needs to be usable from a common space, as in the table in the common house. This means people should not be expected to have to enter a username and password every time they walk up to use it. A couple of solutions come to mind:

1. A "common" user which can perform a subset of sign-up tasks for any user. To wit:
   1. Sign up to Cook.
   2. Sign up to Eat.
2. Key fob login option (rfid or nfc): touch your fob to a magic pad and switch to that user.
   1. In the "common house mode", the user should be able to logout and the system would revert to the common user.
   2. In the "common house mode", if the user has not interacted with the system in > xx time (60 secs?), log them out and revert to the common user.

Other ideas?

As a user, I want to sign up to cook in the context of a meal rotation.

If you look at the calendar, there are colors under each date when a cook is required. These colors indicate a meal "rotation," in other words the minimum amount of time necessary for each member of the co-housing residents to cook in pairs.

This needs to be replicated EXACTLY so that cooks know how frequently they need to sign up.

No field for entering Extra Meals on the Meal Form.

As an administrator, I would like to restrict access to the Common User to a holder of a uniquely identifying feature.

Had trouble wording this. What I mean is this:

You should not be able to log in to the the Common User (CU) from the internet-at-large. You should only be able to log in to the CU from a restricted set of hosts.

My security speak is probably off here, but "Uniquely Identifying Feature" could be an X.509 certificate, a USB key with a secret on it, something that only one computer could have. Even better would be to have that further restricted by IP, MAC address, or something similar.

Even better would be if an administrator could set that up once, and then the machine in question would never need a password entered again. This would help if the admin is on vacation and the machine needs to be rebooted, it could reboot back into a usable state without needing to enter passwords.

The purpose of further locking down by IP would be if the device were physically stolen and moved off-premises, the thief could not use that cert to log in to CU and cause havoc.

Overkill you say? Madness, you say? Perhaps, sir, perhaps. Or perhaps... genius!

As a user, I want to see the title of each week fully written out and rendered in MS Comic Sans

HAHAHAHa just noticed that on the pic of the calendar:

As a user, I would like to be able to note my dietary restrictions on my profile, and have that show up to cooks when they view the guest list.

Currently there is a food restrictions list on the fridge buried beneath pictures and other garbage. Useless!

This should be a user-definable profile setting. The cooks' list of guests should always include this information.

As a user, I would like to be able to sign up to eat from a button on the calendar screen.

Much like the "sign up to cook" button, on each date there should be a "Sign up to Eat" button that would open a pop-up with a user dropdown (if logged in as Anonymous), a Meal Preference checkboxes, and an OK and Cancel button.

Pantry reimbursement form