jordanbrown0 / reg3 Goto Github PK

As in the subject.

v3 and v2 use different names for a number of fields - last vs lname, postcode vs zip. Perhaps it would be best if v3 used the same names to make transfer v2<->v3 simpler.

Search performance with large member tables (20K entries). Will probably need to learn to skip searches, so that we don't search until we've processed all of the input. (But keystroke suppression during RPC will lose keystrokes; for this case we need to reverse the priority of the two.) Confirmed that this is a problem with 20K entries. Right now I don't remember why I felt the need to suppress keystrokes. Maybe it would be sufficient to suppress searches while a search is in process.

Because the conflict resolver operates at a low level, it compares and displays record keys rather than the human-friendly data the keys point at.

The most likely place where this would apply is in station records, where there are cross references to printers and servers.

This is probably mostly a non-issue, because these are data items that are unlikely to be the subject of conflicts.

The conflict resolver could use schema data to retrieve the matching human-friendly data.

When reprinting a label, v2 optionally requests a justification and optional associated amount and logs them, in support of lost-badge fees and money accounting.

As in the subject.

v2 has PESO, standard infrastructure that puts a "press escape to start over" note at the top of (almost?) every page.

v2 has several miniature reports printable on labels:

• picked up by day
• new by day
• new by day and class

Their value is questionable and they can be unreasonably verbose (multiple labels).

v2 has a simplistic attribution scheme - during startup, you're asked for a name and that name is recorded in log entries. There is no authentication - you can use whatever name you like - but in theory it would let you find who handled a particular transaction.

v2 has a number of canned bulk corrections / standarizations, e.g. replacing "United States", "U.S.", "USA", et cetera with a canonical value.

v3 has table-driven entry-time corrections, but no bulk corrections.

v2 has a (recently added) feature for fixing times introduced by erroneous system clocks.

For v3 this is less of an issue:

• the server time, not the individual station's times, is used for the records. Getting one clock right is easier than getting N clocks right.
• the stations all display the current server time, making errors more obvious.

Because the free-text search mechanism operates at a low level, searching the actual contents of the record, it matches the codes in the table rather than the descriptions that are shown to the user.

It doesn't seem practical to teach the free-text searcher to search the descriptions. Storing the description would be possible, but ugh.

Probably best is just to accept it, and arrange that the various UIs show the codes so the user knows what to search for.

Similarly, cross-references using record keys would have the human-unfriendly keys searched. For instance, you could not search the station table by printer name. Although that's even less friendly than the class/category issue, it's also on a far less prominent use case.

Some or all of the member tally reports should show money received, give or take questions associated with receiving multiple payments over the course of time.

v3 needs similar reports.

Perhaps reports based on a transaction log would be a good substitute. Ref #35.

Although JS does not have concurrent processing, its event-based processing can be interleaved. An RPC request can be sent, and while the client is waiting for a response it can receive a keystroke or mouse event.

Some attempt has been made to handle this, suppressing interactive events while "busy" processing a previous request, but it's not really satisfying and it seems error-prone.

Perhaps it would be better to automatically suppress interactive events starting with a Nav event and either automatically reset on base.switchTo or on an explicit request (e.g. in response to an error). (Better still, the error UI could automatically reset it.) There would still be an opportunity for error, if processing an event does not lead to one of the reset cases.

As in the subject.

In Reg v2 if you type "same" as the address it copies the address from the previous record. (I don't remember whether it's the last record in the table, or the fix-last record.)

Ideas:

• type "same" as in v2.
• button after address.
• button in Nav Bar. (Easy but not obvious.)

v2 has rudimentary logging, and includes an "other transaction" mechanism to let one manually add a log record. The theory was that you might use it to record miscellaneous petty cash transactions.

It's not worth much unless we make the money accounting a great deal better than v2.

v2 handles both "published" upgrades, where specific from-to combinations are listed, and "ad hoc" upgrades, where you can select an arbitrary class and say how much the upgrade costs.

v2 originally justified the member's names to the left. Later, the ability to center or (almost uselessly, but for completeness) right-justify the names was added.

v3 currently supports only centering.

Printing a label for a long name requiring several shrink steps took ~500ms for the design phase. Although that's not a lot, it might be a scalability problem.

One way to reduce this time is simply to have fewer font sizes.

v2 has a permissions check for its (S)earch feature.

The (S)earch feature and its corresponding permissions check largely went away when search became the primary UI for locating members.

The value of the permission check was always marginal.

This looks like it won't be needed in v3.

v2 looks up previously-known people from a MASTER table and fills the data in.
It also retains the ID from MASTER so that (in theory) information from the current convention can be easily used to update MASTER.

v3 doesn't have a separate step for entering the new member's name, making it unclear when the search would happen. Also, v3's standard search mechanism is a free-text search, not very compatible with being the first step in entering the name.

Perhaps (P) should search both current members and previous messages, allowing you to select "add new".

mkbat creates the batch file used to start the server. It doesn't seem to work in some cases, probably because the variables used are available in Windows 10 but not Windows 8.

v2 optionally asks the operator to justify any zero-cost memberships created, and logs the reason and operator's name.

v2 allows you to specify up to four custom fields - giving a name and label for each. You can set and view these fields, but they otherwise have no meaning.

(Except that "phone" is classically a custom field, and has been used in the "print phone number on second label" feature.)

v3 adding this feature would be mostly straightforward, except that you'd have to be able to specify which page they would appear on. A data type, default, and other metadata would be gravy.

Some of the current directly-supported fields (e.g. Position) could perhaps be backed out in favor of supporting them as custom fields.

In v2, when the "note" field has contents the user is required to acknowledge reading it before proceeding with other operations on the record.

Perhaps there should be both "ack-required" and ordinary notes, but something along those lines seems appropriate.

E.g., correct "st" to "St." or whatever we'd like to standardize on.

But caution for names like "Ave de la Whatever" or "Boulevard Way".

In v2, a transfer was quite limited - it was little more than an ordinary edit, with a different MASTER id and different logging. In v3, since membership numbers are no longer the true key for the record we could retain the entire transfer history, marking old instances of the membership as transferred and creating new records.

As a matter of taste, and also for non-US locales that use 24-hour time.

v2 has an option to, when the member has a badge name, also print a real-name label for the back side of the badge.

v2 has a duplicate detection report that applies "custom filtering" - e.g., having "Bill" match "William".

Perhaps that matching/substitution could be driven by a table.

v2 has mm/dd/yyyy pretty deeply burned into it, making support of non-US dates problematic. v3 uses yyyy-mm-dd natively and translates for display and edit, so could readily support alternative layouts - notably the dd/mm/yyyy form commonly used outside the US.

Alternatively, v3 could always use yyyy-mm-dd form, which would be unambiguous and understood (albeit not "local") worldwide.

v2 has a summary report printable on a label, roughly equivalent to v3's (R)eport (T)ally (S)ummary report. This report is very useful as a simple way to give membership data to convention chairs, newsletters, et cetera.

v3's RTS has stub support for printing the report on a label that needs to be completed.

As in the subject.

As in the subject.

v2 has a "hotel audit helper" that searches the current convention's membership list and the MASTER list, in support of walking through hotel records identifying those guests who are associated with the convention and so should count against convention hotel guest requirements.

Changes in hotel policies seem to mean that the records are no longer available and so this feature may no longer be necessary.

v2's main menu shows the number of memberships left in the station's number range. v3 has less of an issue since the number ranges are per-server and so can reasonably be much larger.

v2 has a report giving all information about the list of membership classes.

The full corrections table is scanned and most records (since most are "member" corrections) are retrieved, on every edit-save. This is dramatic overkill and might be a scalability issue both as the number of corrections increases and as the number of stations increases. It would be a total waste if the corrections mechanism is supported in the DBManager infrastructure.

Correction data is relatively stable and so caching it for a long time is reasonable.

Perhaps tables could have an automatically maintained generation number or last-change time, and the caching mechanism could retrieve only that change indicator, and reload the full set of data only when there has been a change.

v2 has a permissions check for Prereg.

Since it is quite difficult to come up with a use case for disabling prereg, this probably won't happen in v3.

v2 has a transaction log that records most user operations. It has rudimentary support for replicating the log between stations.

v3 has no such log.

Should the log be maintained as a v3 table it would automatically be replicated as part of normal replication. Should it be in a separate v3 database it would not be automatically replicated but could be readily separately replicated.

There is a question of whether the transaction log should be maintained by the client (which has semantic knowledge) or by the server (which sees every change flow through a few points).

The v2 report for memberships by class tallies free vs paid; the v3 version does not.

v2 has a report showing the details of all published upgrades, those with manually listed from-to pairs.

v3's reports can be displayed or printed, but so far have no good way to be exported to a file. Perhaps CSV export would be an appropriate replacement. Or perhaps there would be a button that would pop a plain-text version of the report.

v2 adds a note to its primary member display when the membership has been picked up.
v3 has the same information on the second page with other "bookkeeping" data, but the pick-up information really needs to be front-and-center.

v2 has a number of membership lists:

• class, number, and name, by name
• number and name, by name
• one line class, nujmber, name, and address, by name
• multiline class, number, name, and address, by name
• one line class, number, name, and address, by name, with check box
• class, number, and name, by class and name
• class, number, and name, by class and number
• one line number, class, name, and address, by number

It isn't clear how many of these are worth carrying forward. As we decide this can be split into multiple issues if necessary.

v2 has a setting controlling the number of lines per page on reports. This setting is unnecessary for printed reports in v3 because the browser will break pages appropriately.

However, it may still be appropriate for a plain-text report to file, ref issue #10 . (But note that in v2 we often found it desirable to disable pagination.)

Input cleanup (e.g. "U.S.A."=>"US", "Calif"=>"CA") is currently done at save time. It would be cool and more obvious if it was done on a per-field basis and so visible as soon as you tab away.

v2 has a mechanism for deleting a member record. In v2 that deletion is not permanent unless this station is the only one with that record; it will be replicated back in from other stations.

v3 could readily have a real delete mechanism, where the deletion would replicate. (The major thing holding it back is the fact that "members" doesn't use the common DBManager infrastructure, which has a built-in "delete" option.) Deleting a record would be helpful in cases like duplication where there is no money involved.

As a lesser possibility it could be desirable to have a non-replicating deletion as in v2, but I'm willing to discard that possibility.

v2 has a mechanism for "vanity" membership identifiers, which are arbitrary and perhaps non-numeric. They are in addition to the "real" membership numbers, which are the primary keys for the records.

v3 uses an artificial key unrelated to the membership number, so the membership number is just another piece of data, albeit automatically generated. A vanity number scheme in v3 might just be a matter of allowing the membership "number" to be editable.