g3n35i5 / shop-db2 Goto Github PK

In the long run the administrator interface should be implemented in react-admin. This requires some changes to the API. For example pagination must be supported.

The models.py file is too long, the classes should get split up in separate files.

ATM, most of the resource updates use many lines of code. It should be possible to update a resource by simply calling item(**data).

Some routes (especially login and registration) should be limited in time to avoid misuse.

All products should be listed, even if a user makes the request. Otherwise there may be problems with the display of the history.

Users should also be able to be deleted, even if they have already been verified and have entries in the database. Before a user can be deleted, his credit must be balanced. This can be done automatically by entering positive or negative credits in a new "Loss/Profit" table. At the same time all references for this user have to be deleted.

There should be an optional limit for listing purchases.

System users should be users like "event" or something like this. They shouldn't be able to do purchases by default. Only administrators should be able to use these system users.

There should be a possibility to manually enter the inventory of countable products and thus determine how many products have been purchased and how many have been lost (stolen, forgotten to do a purchase, ...).

I propose two new tables for implementation:

• Stocktaking
• Stocktakingcollection

Explanation:

"Stocktaking" means the process of determining how many units of a (countable) product are available.
A stocktaking collection is a collection of several "Stocktakings", i.e. the determination of the quantity of several products.

The "Stocktakingcollection" can now be used to determine how many products
have disappeared since the last inventory (or have been added, which is
unlikely).

A profit or loss can now be determined for those products for which the following applies:

• They must be countable
• A physical inventory must already exist, since only actual values can be
  determined for the calculation.

The definition of profit and loss is as follows:

• There is a loss if, for example, 5 products have been purchased since the
  last inventory, but there are 7 fewer products than in the last
  inventory.

• An optimal result is when the target and actual values are identical.

• There is a profit if more products are counted than should actually be
  there.

The sum of all profits and losses in a stocktaking collection is then the total profit or loss.

When an api user requests a resource, it does not get a user object as expected, but an object wrapping a user object, with the text identifier "user". Not only does this lack a purpose, as the requester already nows what he expects at request-time, but it complicates both your code as well as the code of external projects accessing the api, likely leading to bugs.

This does not only apply to the user info but to all api paths in the file.

Filters like "purchase between two dates" or "purchase before/after date" should be possible

When buying multiple products, the system apparently checks the validity for each article separately.
Example: When buying a crate of beer (x30) and "buying" the return value of the crate (Pfand) while not having enough funds to buy the beer (e. g. the account is too close to the - 20€ limit), the system rejects the beer puchase but logs the return fee, resulting in a net gain for the user account without a notification message.

I want to remove the Payoffs table by handling all purchases of products as replenishment. For this purpose, products that are not sold to end users, such as "coffee beans" or "dishwasher tabs", should also be maintained in the system.

Administrators must have the possibility to insert purchases for users with insufficient credit

It should not be allowed to filter/sort/etc. by all columns!

The maintenance mode could, for example, also be used for stocktakings. Administrators may want to be able to access all routes despite the maintenance mode. Another point is that the status, whether shop-db2 is in maintenance mode or not, must be persistently saved. This means that not only the entry in the configuration has to be changed, but also the file. This ensures that shop-db2 is still in the status it was before the restart.

The user verification routes should be replaced by updating users, listing users with filtes, etc.

The profit and loss account is not correct. It is fixed together with #2.

There should be a possibility to summarize all user purchases, deposits, etc. at a time determined by the administrator. Thus, the size of the database and therefore the loading time can be kept within a manageable range.
An example: A user has made 100 purchases in the last quarter with a total amount of 150€. This amount should now be entered as "Billing" and all purchases deleted.

Since we have "not-for-sale" products (defined by a "not-for-sale-tag"), we can drop the "payoffs" table. Since this job can't be done automatically with an alembic script, it is necessary to manually migrate the payoff entries to the "replenishmentcollections" (resp. "replenishments") table.