ubersystem icon indicating copy to clipboard operation
ubersystem copied to clipboard

As a Treasury DH, I would like uber to make my life easier.

Open BlueHat-GURU opened this issue 6 years ago • 5 comments

Events have treasury departments. Event management software should recognize and support this.

Features (in no particular order):

  1. Have a page where departments that need cash can set up their schedules, and choose which cash box profile best fits their needs from a (radio button) list of said profiles.
  • Schedule is first delivery time for each day, end time for each day, and interval in hours.
  • Might need a radio button for departments which only need one cash box per event or per day, or the above profile.
  1. Have a page where Department heads can select which of their staffers (or already existing roles) can sign for cash boxes. This needs to be a new cross-department role. This is the part where I expect to most need help.

  2. ~~Config file needs to include which departments even get cash to begin with.~~ Per conversation with Vicki, have a checkbox for this in the DB.

  3. Use the above data to generate:

  • the ledger spreadsheet file for the event (this is easy)
  • generate the correct number of signing sheets for the event
  • generate lists of who is allowed to sign
  • ~~generate locations? (is which room which department is in stored in Uber/Reggie anywhere?)~~
  • generate the list of who is allowed in the treasury room
  1. Have a "monopoly$" add-on for the above (for mpoints), which doesn't have to be included.

  2. A page for departments to put in event mpoint requests, with entry fields for each denomination each day.

  • ~~Preferably this automatically deducts from the department's budget for the event, with the latter stored in configuration.~~ Mpoint budgets under discussion.
  1. Again, have department heads able to select which of their staffers can sign for mpoints, with this as a role for all departments receiving mpoints.

  2. Use this to generate the correct number of mpoint signing sheets, and appropriate pages in the ledger.

I can handle most of this; in particular, the generation of other files and materials is a solved problem. I don't anticipate the UI portions of this being excessively annoying.

Are there any good resources for how to use the API for this?

BlueHat-GURU avatar May 06 '19 00:05 BlueHat-GURU

How about this?

Current formats

  • Creed -> Article
  • Canon -> Articles
  • Catechism -> Catechism
  • Confession -> ChaptersOfArticles
  • HenrysCatechism -> CatechismOfCatechisms

Future formats

  • ChapterCatechism -> CatechismOfArticles

NonlinearFruit avatar Jan 26 '21 04:01 NonlinearFruit

How about this?

Current formats

  • Creed -> Article
  • Canon -> Articles
  • Catechism -> Catechism
  • Confession -> ChaptersConstructedOfArticles
  • HenrysCatechism -> CatechismConstructedOfCatechisms

Future formats

  • ChapterCatechism -> CatechismConstructedOfArticles

NonlinearFruit avatar Aug 12 '22 00:08 NonlinearFruit

Current formats

  • Creed -> Article
  • Canon -> Articles
  • Catechism -> Questions
  • Confession -> ChaptersConstructedOfArticles
  • HenrysCatechism -> QuestionsConstructedOfQuestions

Future formats

  • ChapterCatechism -> QuestionsConstructedOfArticles

NonlinearFruit avatar Sep 04 '23 18:09 NonlinearFruit

It seems that what you're looking for is a standard way of asserting different value classes (key names).

My background is in ontologies and standards for linked data, so maybe this suggestion is overkill, but it might help to have generic types that are reusable and whose meaning stays the same no matter where the information shows up. So, whether they show up in a creed or a catechism or a confession, it doesn't matter -- a proof gets the key "proof" and the value is the string literal, a chapter gets "chapter" as a key, section is "section", a question gets the key "question", a license gets "license", etc. A question with a number is just a unique element ("question") and it has an ID ("1").

Then assert that the JSON object is part_of / has_part the object. Viola. All 107 questions that are part_of the WSC are the WSC questions.

Too much?

jonathanvajda avatar Mar 10 '25 00:03 jonathanvajda

We have a fairly defined structure (types) and the tests assert that this structure is followed. The issue here is have a predictable naming structure for different creed documents. We currently have:

  • CreedDocument<CreedContent>
  • CreedDocument<CanonArticle[]>
  • CreedDocument<ConfessionChapter[]>
  • CreedDocument<CatechismQuestion[]>
  • CreedDocument<HenrysCatechismQuestion[]>

NonlinearFruit avatar Mar 10 '25 14:03 NonlinearFruit