Expand Housekeeping into a generic Household Staff module

[ulsklyc]

Moved here from issue #591 so that feature ideas live where the rest of the backlog is discussed. Originally proposed by @ContatoLucasSonntag - full original wording in #591.

The idea. The Housekeeping module is built around cleaning staff, which works well for that. But many households also rely on gardeners, security guards, doormen, drivers, cooks, babysitters, pool maintenance, electricians, plumbers and others. The proposal is to evolve the module into a generic Household Staff module: every staff member carries a category/role, and everything else - schedules, check-in/out, daily or hourly billing, chores, supply requests - stays as it is. Existing records would become "Housekeeping" entries, so nothing is lost.

Why it is interesting. It keeps the whole functionality and only widens what may be recorded, which is a small change for a noticeably larger group of households.

Open question for the discussion. Whether the roles are a fixed list plus "Other (custom)", or fully user-defined categories like the ones the other modules already use. Related from the other direction: #736 (cleaning plan for households without a cleaning helper) - the two together map out how differently households handle this.

[ulsklyc]

Picking this up with what the schema says, because there is a constraint here that decides the whole shape of the answer - and it is not the one the discussion has been circling.

Every housekeeping worker must be a Yuvomi user account. housekeeping_workers.user_id is NOT NULL UNIQUE REFERENCES users(id) ON DELETE CASCADE. There is no way to record a worker who does not have a login.

That is defensible for a live-in or regular helper: they check in and out themselves, they see their own chores and supply requests, the module is partly their interface. It is the wrong shape for most of the roles in the proposal. Nobody creates a household account for the plumber who comes twice a year, or the electrician, or the babysitter from down the road. And a user row is not free - it carries permissions, sessions, invitations, an entry in every assignment picker in the app.

So the open question in the original post - fixed role list plus "Other", or fully user-defined categories - is the second question. The first is:

Is a "household staff member" a person with an account, or a record about a person?

Those lead to different modules:

(a) Widen what exists. Add a role/category to housekeeping_workers and keep the account requirement. Correct for regular, recurring help - a gardener who comes every week, a nanny, a driver. Small change, exactly as @ContatoLucasSonntag described: existing rows become "Housekeeping", nothing is lost. But it does not reach the plumber, and the group of households it opens up is smaller than it looks.

(b) Decouple the record from the account. Make user_id nullable and let a staff member exist as a plain record - name, role, rate, notes - that may be linked to an account when that person actually logs in. This reaches everyone in the proposal. It also means check-in/out, chores and supply requests need an answer for the account-less case: someone else records the visit on their behalf, which is a different interaction than the module has today.

I lean towards (b), because (a) mostly widens a label while the real limit stays where it is - but it is a migration on a table with a NOT NULL constraint and live data behind it, so it is a deliberate decision, not a side effect.

On the original open question, once that is settled: user-defined categories, matching what the other modules already do, rather than a fixed list plus "Other". A fixed list is always missing someone's role, and "Other (custom)" is the shape that admits the list was wrong.

Related from the other direction, as noted: #736 wants a cleaning plan for households without any helper. Taken together, the three cases are "no helper", "regular helper with an account", and "occasional trades without one" - and they are far enough apart that trying to serve all three from one module is worth questioning before building.

@ContatoLucasSonntag - in your household, do the people you would want to record log into Yuvomi themselves, or would you be keeping the record about them? That is the (a)/(b) answer.

[Azooz-AI]

I would love to also see permeant maids that actually live with us and avoid the hourly rate all together, it will mainly just show the chores and schedules they need to complete on that particular day.

[ulsklyc]

@Azooz-AI Useful, because your case sits on the opposite side of the question this thread has been stuck on - and that is what makes it worth answering separately.

The open question was whether a household staff member is a person with an account or a record about a person. The plumber who comes twice a year is clearly the second: nobody creates a login for him. A live-in helper is just as clearly the first. They are in the house every day, they have their own schedule and their own chores, and the module is partly their interface - checking in, seeing what is due today, requesting supplies. The user_id NOT NULL that makes the module wrong for the plumber is exactly right for them.

So your request does not need the module to be reshaped at all. It needs two smaller things, and they are separable:

1. Billing you can turn off. housekeeping_workers.rate_type currently knows daily and hourly. Both assume a rate. A live-in helper on a monthly salary has neither, and someone in your situation should not have to enter a fake day rate to make the form accept the record. That is a third value - call it "none" or "not tracked" - and everything downstream that computes a payable amount skips those workers. Small, self-contained, and it does not touch anyone using the module today.

2. A view that is chores and schedule only. Which, once billing is off, is largely what is left: with no rate there is nothing to bill, so the payment surfaces have nothing to show and can stay out of the way. Worth checking whether that falls out on its own or needs an actual change - I suspect mostly the former.

Neither of those waits on the staff-category question. They are the same module doing what it already does, with the payment part made optional.

The category axis you would still get from the broader proposal: recording that this person is a housekeeper and that one a nanny. But that is the cosmetic half. The part you actually asked for is the billing being optional, and that one is worth doing regardless of how the fixed-list-versus-free-categories question is settled.

Staying open. Between your case and the plumber case, the thread now has both ends of the range described, which is more useful than either alone.