TL;DR :
The original request:
- Direct the User straight to an Entity Screen upon Login
- Stop a Work Period End based on conditions and redirecting to an Entity Screen
The New idea to facilitate this:
- Create a new
Navigation Button Widget
that could be used on Entity Screens. This Widget would have access to the functions contained inMain Menu
(Navigation Screen). - Add new Action for
End Work Period
- Change
Work Period Ending
Event so that it can be handled and the End can be aborted.
I would like to be able to run conditional check when we are about to end a Work Period… even something as simple as Ask Question Action, and if the User selects “No”, we don’t End the Work Period and instead take them back to the POS/Ticket or a Custom Entity Screen.
It would be nice if we could automate the checklist, and prevent Work Period End… similar to the way it already is for Open Tickets. So we could have other messages indicating that something needs to be done before the Work Period can be Ended.
- There are 4 Open Tickets - with a button that goes to a ticket list.
- There are unfinished Inventory Purchase Transactions - with a button that goes to Entity Screen.
- Etc.
My first idea was a simple Question on Work Period Ending Event: “Are you sure you completed Inventory Transactions? Yes/No” If they answer No, redirect to Entity Screen.
Either the User can confirm this, or even better, we automatically check our conditions and prevent Closing.
I use an HTML Widget for Inventory, but possibly with Scripting Actions, I can set a flag in Program Settings from Javascript to indicate that there are Inventory and Account Transactions still Pending, so they can’t close the WorkPeriod.
While we are talking almost specifically about TimeClock (Employee Entity) at this time, I too have custom Entity screens containing HTML Widgets that control my Inventory directly (Supplier Entity and Warehouses), among other things. In the case of the Supplier, I don’t really care about the Entity (for my current purposes); it just makes sense to put the HTML on that type of screen.
The Entity Screen is a powerful feature and a great way to customize what you see, so I can understand why we shouldn’t need to duplicate it.
So what do we need to work within the current infrastructure?
Display Entity Screen
orSelect/Load Entity
Action: shows an Entity ScreenNavigation Button Widget
: Buttons that have access to theState
ofEntities
in order to constrain the available action(s) like whether the button is enabled, disabled, visible, etc. (like Automation Commands), and also have access to the permission of theUser
, andEntity
State like Logged-in Clocked-In, and Custom Data “permission” Fields like Employee Position (Manager, Cashier).Navigation Grid Widget
: not necessary if we have button-level control, but cold be useful- Navigation Permissions (we have this already - it may need expansion)
End Workperiod
Action: nice-to-have for automation and Close-out checks.Abort Workperiod End
Action: would imply that we have the ability to Abort closing the WP within theWork Period Ending
Event
We need access to these features after User Login, so that we can go directly to the Navigation Widget that is located on the Custom Operations Entity Screen, and bypass the regular Navigation Screen. That would suffice for TimeClock.
Personally, I would like to attempt to keep the User disconnected from the Employee Entity, simply because I don’t want, nor need all of my Employees to Login. The Manager User can Login, and the Employee Entities can ClockIn/Out under the same login. All this Login/Logout for a small operation is unnecessary. But I can understand reasons to be able to check both User permission and the Entity “permission” (custom data field) and the Entity State.
As I continue to re-read and edit what I just posted, and think about it more, I think this may be the most important thing here:
Navigation Button Widget
:
Buttons that are mapped to Navigation Actions.
The Widget needs access to:
Entity State
: such as Clocked-In/Out, to constrain the available action(s) such as whether the button is enabled, disabled, visible, etc. (like Automation Commands).Entity Custom Data
“permission” Fields: such as Manager, Cashier, Cook. Why? because I might not want Entities linked to Users.User
orRole
Permissions
.
If we have a Navigation Button Widget
that we put on an Entity Screen, there would be no need for Main Menu
, because the Entity Screen (with the Navigation Widget) contains the functionality of the Main Menu.
If the Entity Screen contains the functionality of Menu Menu, why would we need it? Where do we need “to go back to”?
Look at my mockup for a Custom Entity Screen containing Navigation Button Widgets
. The LightBlue Buttons are Navigation Button Widgets
, and the rest are Automation Commands
(including the WorkPeriod buttons). We have everything we need on this screen - and it is customized for the User or Role.
When we click TimeClock, it takes us to another Entity Screen, and when we click Close (Automation Command) on that TimeClock Screen, it brings us back to this screen. This screen supplants the original Main Menu (Navigation) Screen.
If the Navigation Button Widget
has the functionality that I think it could have, I personally would have no need for Main Menu
.
@emre, I like the idea of removing the Work Period Navigation and using separate Automation Command buttons so that we can run checks on States before we decide to Open or Close.
Login could take the user straight to Entity Screen with Operations, like the following…
Local Settings:
User Role: