In the cash component, some manager could access the snapshot history of his application by clicking on the 'History' dropdown button and choosing a snapshot. All well, but what happens when there are many (many, many, ...) snapshots in the application.

To avoid ugly pages, the dropdown could only show the first 10 snapshots and propose a link to a list of snapshots. This list of all snapshots could be some modal window or a separate page.

In current snapshot data, every sale date is said to have been made on 31 May 2015 15:25.

Some Blade component that are used in all templates such as global CSS, JS, header and left menu are currently located in the "views/app" folder, but it would be more logic to put them in another folder such as "views/layouts" or "views/global".

First of all, the RepositoryException is currently located in the app/Repositories directory. It would have more sense if it was located in the dedicated app/Exceptions folder. (http://laravel.com/docs/5.0/structure#the-app-directory)

Then, in recent "API controllers" such as the ProductController or SnapshotController, almost every method has a try/catch who catches an RepositoryException and just calls the method

return $e->jsonResponse();

Could it be possible to move that logic to the exception handler located in app/Exceptions directory? The API controllers would look nicer and all the logic would be located in one single point...

The application routing file (app/Http/routes.php) isn't using any route pattern constraints. Could be a good idea to enhance the security. Or should all controllers perform a check?

In the snapshot component, it could be useful if the progress bar above the details also displayed the free sales. It would look something like that:

[ paid sales ] [ free sales ] [ cash snapshots ]

Registered a few sales around midnight (3 before, 2 after). It was 00:15 when the stats component gave the following error:

Setting a standard icon and title to all pages

When deleting a category, the application still that category as the current one. This means that the managers can simply add a new product to that category and it won't be blocked by the server or the client.

Esthetically speaking, I thought of a big table with base types as headers and products as rows.
In combination with the accordion effect on headers, the size should not be a problem.

And why not make an edit button at the corner of the page to display/hide all editing elements ?
This way, the list can be made entirely "linkable".

I made a "fresh" installation of Barmate using the newly created installation wizard. Everything worked well, the installation process caused no bugs and all components are working but not the cash component.

When going to the cash component page, I got this error:

First tried to add some sales, but that doesn't worked.

When putting Barmate on a server (with the "public" directory as the Apache "DocumentRoot"), it would be great to create an installer that would allow to install Barmate without touching to a terminal.

At first thought, it would be like that:

• Go to my-domain.com/install
• First page checks if the system requirements are OK (PHP version, all extends installed, mod_rewrite enabled, storage folder with write rights, ...).
• Second page asks for the database credentials and the timezone. The database connection will be tested when submitting the page.
• Third page asks for the admin account details (more secure than creating a default [email protected] user).
• Redirecting to login page and restricting access to the install routes.

Just after installation and initialization, I could not type in the paid amount for a sale because the keypad would not respond. However, I can click Send, it doesn't make any sale (no stocks removal) but the ticket becomes empty...

There is still one component of the application that has not been redesigned since Barmate has changed of style: the login form. Yup, always the same pure-bootstrap style...

It would be great to redesign this form so that it has the same style as the installation wizard: clean, simple and with the Barmate logo.

Sometimes, when paying, the clear button on the keypad will set 'undefined' as paid value rather than removing last encoded digit.

Try it out:

• create a product in the STOCK component
• register some sales in the POS component and click always on the "Free" button
• sales are now registered and product quantities updated, but when going in the CASH component, you can see that Barmate thinks that all sales have been registered.

First thought is that the predictive cash snapshot algorithm must be a little bit redeveloped...

Maybe do a tinier button or put a confirmation dialog to avoid mistakes and bad jokes.
After all, free sales don't happen SO often...

The app should forbid someone to continually add a product when it reaches the stock value.

Barmate's code could be a lot better if Grunt had the PostCSS (for vendor prefixes), JSHint and CSSLint plugins. Perhaps see if we can use these plugins for the next releases...

Some big missing function: when registering a sale in the POS component, the sale and snapshot detail are saved to the database, but the product quantity isn't decremented in the products table. Best way would be to call the update() method in the ProductRepository.

The current version of Barmate uses Laravel 5.0. In order to stay up to date with the following releases of the framework (http://laravel.com/docs/5.1/releases) it would be great to perform an upgrade to the 5.1 version.

The changes are described on the following page: http://laravel.com/docs/5.1/upgrade#upgrade-5.1.0.

It would be more interesting to have the progress bar in snapshot details based on the total of cash by operation type in place of the number of operations by type.

For example:

(sum of sales = 10€ ; sum of cash op. = 20 €)

instead of
--------- 3 Sales --------------------- 1 Cash op. ---------
| ------------------ 75% ---------------- | ----- 25% ----- |

have this
--------- 3 Sales --------------------- 1 Cash op. ---------
| ------- 33% ------ | ---------------- 66% --------------- |

In a sale transaction, the payback value doesn't update at all (it stays at 0€), no matter what paid amount is entered.

When putting Barmate in maintenance mode using the artisan down command, the page displayed is views/errors/503.blade.php. Looks actually really nice and minimalistic, but has nothing common with the Barmate theme (dark blue/white).

Perhaps spend some time to redesign the page?

No big deal.
The back button icon of the connection history page in user section is not really appropriate.
I'd rather see a left oriented arrow or something approaching (the cross means 'cancel').
And I think that the links in stock manager (select, edit and remove) won't be easy enough to click on in front of a touch screen.

Barmate's current first page is just a white screen with a link to the login page. This page was meant to create a home page for the project, but actually doesn't make much sense. It would be better if the login page was the first page that the user sees.

This involves some little modification in the routes.php (https://github.com/Saluki/Barmate/blob/master/app/Http/routes.php around line 11)file, the guest, user and manager middlewares (who must now redirect to / and not to /login) and the login controller (when leaving the application, also redirect to / and not to /login).

Would it be better for the end user if he had only on "public" folder and one "barmate" folder (with all system files).

What should happen then ?
Why not start the application with a snapshot ?

Before application gets too big, perhaps rethink a little bit the organisation of the repositories:

• Adding a global interface who provides some method declarations like find/all/...
• Each repository would have his own interface: for example, ProductRepository would have a ProductRepositoryInterface with his methods. The ProductRepositoryInterface would extends the global repository interface
• Creating a file structure to store interfaces, implementations and mocks (ProductRepositoryInterface, ProductRepository and ProductRepositoryMock)

The advantage of using mocks for repositories is that controllers can then easily be tested with phpunit without having to carry about some database

After registering only sales (no cash operations), the short statistics in the cash component dashboard gave this: http://s11.postimg.org/qs22cumqr/Screenshot_from_2015_06_03_19_15_43.png

Or something went wrong when registering a sale (bad type, ...) or the short statistics in the cash component were wrong.

Since the project has moved to the GNU General Public License v3, all developed files should start with the following license text:

Barmate.
Modern and intuitive POS web application written with the Laravel framework.

Copyright (C) 2015  Corentin Badot-Bertrand  (http://badot.corentin.me)

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

New feature to develop before stable release: disabling/removing specific sales.

First though would be to add some "disabled" switch button next to the sale entry in the cash component. A manager could disable a wrong sale if needed.

Watch out! This feature must involve some solid analysis because it directly impacts on the cash snapshot details and thus the computation of the predicted end amount.

In the POS component, when some sales are not synchronized due to server or network errors, the synchronization mechanism is triggered when a new sale is registered.

The following enhancement to develop would be to offer a way to

• manually sync. sales: a button that would allow the user to resend a sync request to the server
• automatically sync. sales: every N seconds (eg. 60 seconds) resend a sync request to the server

Watch out!
Two synchronization request must NEVER happen at the same time (could cause data duplication). In order to prevent that, the most basic solution would be to implement a "LOCK" variable...

Currently, middlewares (aka. filters) haven't been moved from old version to the current. This means that the application doesn't control if the user is authenticated or not and which role he has.

In the users component, a badge appears on the active tab to indicate how many users there are in that category (active or disabled users).

It could be great if there was also a badge on the other tab, which would be more logic.

No big deal either.

Stock

Category title [Add] => Category [Add]
2.1€ per product => € 2,10 / (unit/item)

Cash

This snapshot has no cash operations or sales => This snapshot has neither cash operation nor sale

User

User account for Corentin created => User Corentin added
User Corentin has been deleted => User Corentin deleted
Account is now disabled/enabled => User Corentin disabled/enabled

Connection history (by the way, love the 'private navigation' style on empty page 😉)

Email address => E-mail (is it not always the same ?)
IP address => IP
Login time => Login
10 hours before => 10 hours ago

Titles

Page title : Stock management | Section header : Stock management | Section title : Manage stock
Page title : User Accounts | Section header : User Accounts | Section title : All users
Page title : Connection History | Section header : Connection History | Section title : Connection history for John Doe

Menu

• Bar (App?)

As proposed in issue #24 , it could be very useful that when the products are soon out of stock (<10 products for example), a little orange warning icon alongside the product item in the POS component warns the manager that the specified product is soon out of stock.

The 'update product' button and the 'confirm' button from product removal dialog aren't working.
They do execute the action but they don't disappear afterwards...

When viewing a closed snapshot in the snapshot component, it could be very useful if the manager could see some statistics about the closed snapshot. Otherwise, what would be the purpose of creating snapshots?

At first thought

• showing the "delta" with the next snapshot. For example, the predicted amount of snapshot A is X and the start amount of snapshot B is Y. What's the difference between those amounts? What does that mean?
• showing the snapshot duration. When did it started and when did it ends? What was the duration in hours/day/weeks... Carbon will be very useful for those computations.
• maximum amount in the cash desk and when did it happened.

If something goes wrong on the server side of the POS component (could not register sale, no snapshot, ...) it's correctly handled on the server, but the client does not see any error message.

Would be useful if the client could have some feedback of his transaction. Perhaps use the same alerts as in the stock component.

When viewing a closed snapshot, we can see a little summary of that snapshot (including duration, difference and cash by sales). Seems that the duration algorithm isn't precise enough:

The objective is to enhance that algorithm so that it can give the seconds, minutes, hours, days, ... for the closed snapshot.

Barmate is currently using Grunt as front-end build system. Another build system and great alternative to Grunt becomes very popular: Gulp and is now integrated in the Laravel framework (since version 5.0). A good analysis on both tools: http://sixrevisions.com/web-development/grunt-vs-gulp/ ...

Could it be possible to migrate to Gulp to make the front-end development (CSS and JS minimification, ...) more easier?

http://opensource.org/licenses/GPL-3.0

In the POS component, the user can't see a category without products.

Some solutions:

• Display in the stock component a message that specifies that an empty category won't be displayed
• Display the category in the POS component

This is not really a bug, but can be confusing for the users...

The POS component works well, except there's no validation performed by the underlying repositories. This means, creating and calling the validate(array $data) method in the SaleRepository, SaleDetailsRepository and SnapshotDetailRepository.

When deleting a product

• He is removed from the POS component: that's perfect
• He is also removed in the statistics component: we get some trouble...

The deleted product doesn't appear in some statistics (which actually makes the data wrong). The best way to solve this would be to count all product (including the deleted) in the statistics, but to show next to the deleted product a little icon indicating that they've been deleted (does Font Awesome have some forbidden icon?).

The deleted categories are displayed only if there were still products in the category.

Currently it can't be done within the application, because a category must be empty to be deleted, but if something goes wrong in the database, this bug can appear.

It's a bit restrictive not being able to hide the menu by clicking anywhere outside the menu.
The 'close' button is even not necessary because it's way more natural to tap on the main screen to hide the side panel than to reach one particular spot.

While testing the application on Windows, remembered that the "Droid Sans" font (the font used for Barmate's logos) was not installed on all clients.

In order to provide the same UI for all users, it would be great to include that font directly in the application (with the CSS @font-face rule).