This is a critique of honor societies which do not serve a point in proving someone's "honor". The college requirement is essentially: Join this club to prove you have joined this club. Anyone can join an "honor" society without demonstrating anything related to honor, meaning:
([Joining an honor society] => TRUE) <=> [Being allowed to join college]
Being allowed to drive a car implies having a license and having a license implies being allowed to drive a car. Neither of these implies TRUE - in an ideal world at least.
By the way, TRUE is a tautology because it is always true, which is the definition of a tautology. Unnecessary repetition is not a requirement of a tautology.
Any project with it set is active, any project with it not set isn't. And you set them all to active when you create the toggle.
If the users complain, you make them tell you an specific rule that can you can use to auto-change a subset of the projects in a cron job. Expecting anything like this to have a complete objective definition is delusional.
I’m surprised I’m the first comment saying this, but all I see is a user who needs help expressing their needs but who is not getting that help. Sure they don’t have our experience with decomposing problems and anticipating technical issues, but that’s normal and expected.
People bitch about the existence of Project Managers (I have myself) but then you see shit like this. Breaks in communication and one side needing the ability to express to the other. Some devs can bridge it, some can't.
This is why "sure" or "yes" are not part of my IT vocabulary. "Should" is king. "We should be be able to do" or "that should work."
In the idiocy of stakeholders that want IT to be a magic wand to fix their ineptitude instead of a helpful contributor to their well thought out process, you have to coach everything in the polite "no" that is "maybe" or "should."
One of my managers told me that I need to use words like "will" instead of "should" when talking discovery with clients. I told him only Siths deal in absolutes, which he didn't like as much as I did.
I'm not a yes man, and I'm not going to lie about something I can't guarantee. If something goes wrong, I'm the one that looks like a lying failure and gets to fix it. My clients are internal business users, not actual external customers. Words have meanings, and it's important to use the correct ones when communicating important information.
Should presumes an ideal set of conditions with perfect context.
Could is a much better term as it implicitly accepts real world conditions and a lack of total context by couching the affirmation as contingent upon only the discussion (and prior references) at hand.
But it's pretty fun when the customer says your program does it wrong and you pull out that old Excel, plug in the data and their Excel does exactly the same as your program. It makes the discussion about billable hours a lot easier.