bjorgan / digcross Goto Github PK

Receive keyboard input from RFID card reader, accumulate into a complete card number.

(Split from issue #10)

Add calculator interface for specifying custom prices and amounts.

Use some variant of http://doc.qt.io/qt-5/qtwidgets-widgets-calculator-example.html (possibly). Will need to change license of the project from MIT to GPLv3, but shouldn't be a problem. :^) It is actually distributed under a BSD-license, so don't need to change license.

Add option for retaining items in shopping list after a transaction, for convenience when several users want to transact the same set of items (feature request from Julian).

In order to elucidate that a transaction has happened (since keeping items in shopping list usually means that the transaction failed) and keep track over which users have had this set of items transacted, display a transaction log with list of names when option is enabled. Hide and keep wiped when option is disabled. User list should have wipe option. User list should be cleared every time the shopping list changes.

Add an admin menu (menu list editor, user database editor). Access authentication using RFID reader + PIN-code.

Administration will require switching to the UNIX user having the write privileges for the user database (issue #5) and the price list (issue #1). The admin part of the program might therefore need to be a separate program that will be run as this user, or could use whatever is correct of things related to https://techbase.kde.org/Development/Tutorials/KAuth/KAuth_Basics and https://techbase.kde.org/Development/Tutorials/PolicyKit/Helper_HowTo and use the dbus interface developed as a part of issue #15 and #12.

This might probably become a bit complicated. :-P

Generate menu GUI from the price list.

-----------------------------------
Item 1     Item 2   Item 3 
[photo]            [photo]             

Item 4     Subcat 1

Subcat 2    [arbitrary]
----------------------------------

• Should always have a button for choosing an arbitrary price/amount for something, regardless of subcategory (calculator interface? Can do simple sums and multiplications)
• Items with arbitrary price should set an item name that combines the price and current category to yield a price-unique identifier
• Price should somehow be displayed in each menu item
• Pushing Item [n] should add one amount of that item to the shopping list.
• Pushing Subcat [n] should open that subcategory and display a similar menu for the items contained in the subcategory. Pushing items here will add to the shopping list.

Menu GUI should be dynamic and reflect the current price list as edited by the admin interface. Changes in the internal price list data structure should regenerate the menu GUI and its associated signal/slot connections.

Chosen items are immediately signaled to the shopping list using the ShoppingList::newItem()-signal.

Whether the main menu should inherit from QAbstractItemView and become a pure view of the data contained within the price list (as mentioned for the editor in #3) is an open question.

Contains shopping list, list over items to be bought, prices and amounts to be bought.

API:

• Receive signals about new items to be added to shopping list
• Add up the same items when separate signals are sent, but the item is the same

Run the daemon as a separate user: (Redefine DIGCROSSD_USER in CMakeLists.txt, create a new user as a part of the install process.)

User database with connection between card number and name.

API:

• Add card number/username into the database (check against backend whether user exist, check whether card already is added to a different user)
• Edit card number for a specific user (check whether card already is added to a different user)
• Lookup username based on card number

Add a small CLI-application based on the API for writing to/updating the database.

See also http://doc.qt.io/qt-5/qsqldatabase.html. qsqlite?

• The user database must not be writable by the UNIX user running the digcross GUI application, write permissions are given to a different user that needs authentication. Not important for the implementation, but keep in mind for later.
• Stored card numbers should not be easily readable, we are storing sensitive information that could be misused. Salted hashing?

Are there any other security issues?

User database read access could also be contained within the daemon mentioned in #15, so that only card numbers are sent to the daemon.

Create backend abstraction against which the GUI application can interface, i.e. a client against the daemon planned in #15.

(Was: "Dummy backend" with the planned backend communication API. This was moved to #11 instead.)

Draw a map over the classes we need to develop and their internal relations (GUI-wise, signal/slot-wise and wise-wise) and external relations to e.g. files. See also issue #12, #9, #8, #7, #6, #5, #4, #3, #2 and #1. Add to the wiki.

Show an overview over which items have been added to the shopping list and total amount to be processed.

Should be able to edit the amount of each item. Should be able to wipe the shopping list, wipe last added item, wipe items.

GUI editor for prices/categories. Write to file and update the GUI.

How to choose pictures in an efficient manner? Post a request to google for the item name and let the user select and download one of the first displayed images?

(Access from admin interface? Probably not that sensitive, so probably not necessary.)

In order to restrict access to authentication key (#11) , put backend interface inside a daemon (or something similar) run from the admin user (see #5, #1), and let authentication key have read access only from the admin user and process transactions only for users present in the user database/users that can authenticate themselves using the card number. Possibly also abstract away the user database access into this daemon, so that user database can be directly readable only from the admin user.

kryssgui (user) -> kryssd/ragno (admin) -> ufs

Need a client interface on the kryssgui side. Supported communication should more or less be the functionality listed in #12. DBus might be a possibility for communication if this is well-defined across different user processes.

When a card is read, do:

• (Send request to backend for current available amount, display current available amount and payment and ask user to swipe card again to confirm)
• Send request to backend for payment to be put through
• Wait for confirmation from backend
• Display error or report successful transaction and wipe the shopping list

GUI widget for adding user name (write manually?) and receive a card number. Add to user database, display errors as necessary. Access from admin GUI.

Get some feedback from backend to indicate whether username exists in backend database.

Design a simple plaintext file structure for containing the item listing and associated prices, and also say something about the menu structure.

The menu file should support:

• Stand-alone items to be displayed on the main menu
• Categories/submenus containing further items
• Prices
• Item name
• Picture of the item (relative filename path)

Some kind of XML format is probably fine. Can be parsed and read using QXml (http://doc.qt.io/qt-5/qdomdocument.html).

API:

• Design an (easily editable) data structure for the price list
• Read price list from file into a data structure
• Write price list from data structure to file

It is possible that the price list should rather be requested from the backend, so try to take into account that the price list might arrive from a different source at some point in the future.

Price list should be non-writable by the UNIX user normally running the GUI application.

API against remote/external backend:

• Request for existence of given user name (return true/false)
• Balance for a given user name
• Blacklist status for a given user name
• Request for transaction for given user name (return success if transaction was processed successfully, return failure if not)
• Backend status (up/down)

Will probably need some kind of authentication key against the backend. We need to keep the auth key secure, so all direct communication against backend needing the auth key will be done using the daemon in #15.

Find good (pre-existing?) solutions for:

• Widget for specifying amounts of an item in an efficient manner. A simplified calculator interface might be OK. (Moved to #21)
• Widget for inputting usernames.
• Widget for PIN-code in admin interface.