If they are Module-defined but are not SambaPOS-defined, they won’t be magically created in the SambaPOS Database in the [TicketTagGroups] and [TicketTags] tables.
But as we know, we can still Tag a Ticket using undefined Ticket Tags using Automation, and, using GraphQL. So the Tag will be applied to the Ticket - that is, it will appear in the [TicketTags] JSON column of the [Tickets] table in the DB for that particular Ticket.
We could also possibly allow for modification of a Ticket Tag that is found in a particular Ticket that was set by Automation (ie. the Feedback Tag), but it is already starting to get crazy enough. Better to just Module-define it if you want to control it, such as:
var POS_TicketTagGroups = ['TA','TagGroup2','TagGroup3','Feedback'];
I think if any important tag modification are to be required it should be done using sambapos. After I think all we should be doing here is creating a basic enough screen with just enough functionality that will allow a waiter or user to take orders and make some minor modifications where necessary. Any major changes to an order such reopening a closed ticket, changing payment type, and doing a few other things should be doing using SambaPOS.
We can still do this however if many people ask for it. But I think it will be sometime before people see a need for it as it’s a big enough step just to be able to get this to work and know what is happening haha. Took me a bit of trial and error and of course help to get it to work properly. Once more people get used to GQL then maybe there will far more things we can do to it.
For now i think just having this much functionality is good. Once I catch up and actually get something working then I will definitely help by adding a few more features such as departments and a little more complicated stuff to help more people use it.
Just a quick update on progress. I don’t have Text input for Free-tagging yet, but just trying to get things organized …
It has the potential to look very messy, given all the options I am trying to support. I am now considering not allowing Module-defined Tags. It just makes things confusing.
There really is no compelling reason to not define Ticket Tags in SambaPOS (shown in green sections) if you want them to be available for use. Having Module-defined Tags (shown in burgundy sections), is not necessary IMO, so I think I will remove them
So in other words its better to define them in sambapos rather than in the module. So in this case would it just be better to predefine the tags in the group or is there still potential to have a text input for free tagging? You seem to be getting really close
Yes, and like I said, there is no reason not to define them if you want to use them. A Module-defined Tag Group just seems silly to me now.
I think pre-defining SubTags is always best, but I understand the reasons for Free-tagging too. I do use that feature myself sometimes. We will still be able to Free-tag, so long as the TagGroup definition in SambaPOS has the box checked, I will supply a Text input box… I will do that next.
Every time I look at the screen, I keep thinking of ways to re-arrange it for best use of space. Now I’m thinking about moving the Commands buttons to the right, under the X close button, in a single column, like this?
That looks good with this type of view. I wonder though if for example a user pulls out their 6inch phone or phablet and went to that screen whether that area will be clustered up or not. The higher the resolution the more space you can use to fit everything without cluster. Change the resolution to something lower and and see how well everything would fit. I think this way would be the best method to use to ensure useable in many modes on many different devices. This goes for almost anything id add for testing.
On a higher resolution screen i reckon those commands buttons on the right is great! Not clustered and easy to navigate to.
Also have you tested to see what happens if we select the ask before creating a ticket option for ticket tags and how it works in this module? Alongside what if a selection is mandatory and a user forgets to input a tag. What happens then?
This is just something im thinking of. You can think to implement it or not. Choice is yours. But i was thinking about the user login screen and multi tablet and multi user use.
Currently easy way to not get confused with anything is just create new users for each tablet been used and have them logged in at all times… this is fine but what if a system has individual user login preference with auto logout feature integrated, is there a way we can allow a rule to be sent to the module where it auto logs out a user after a delay?
This would be a nice feature to have as it would help to track who took what order and when using tablets and this module.
Like i mentioned, i can easily convince clients to just have tablets with permanent logins for each tablet. But less ideal for those using auto logout feature forcing individual login.
If it is possible then maybe we can add the code. Test to ensure it works. And if it does,have it disabled by default and if a person wants to use it then they can just enable it inside the code by removing the //
I have a small phone, and nothing I do looks good for a small device. We can do dynamic CSS, which I already put in place for Landscape/Portrait switching, but I only have a 10" Tablet and an iPad3 to test with. I cannot imagine this on anything with less that 7 inches, maybe 7.
For example, this is an iPad - you can see the sections for Categories/Menu and the Order List are moved in Portrait mode … and iPad is 4:3 aspect screen …
Here is an Asus T100 … it has 16:9 aspect, so landscape always looks best to me … a little difficult to tell because I had to zoom to 46%, but even Portait is fine on this device…
I cannot make it look good at all on iPhone 6 … it is just ridiculous - got to draw the line somewhere…
Not there yet. None of that is implemented.
In every Module there is an init_module() function. The Special Reports for Ticket Tags are in that section. We need to check the TagGroup Properties for “Ask before creating Ticket” and keep that value in mind, like when you click on a Menu Item, check the value and automatically display the Ticket Tag Screen.
Yep got it. We can work on that once satisfied the tags and everything works to your satisfaction(i say this as you are the designer and im just trying to five feedback and suggestions that may be encourageful and or useful to you. And not at all in a bad way! I love you man!!(no homo haha))
Yes i am aware of this feature. It is a great feature, i personally prefer it. However the voices and experience tells me the first thing a client may ask if they implement actual user names and pins instead of using tablet names is " it would take a person at least 5-10 seconds(oh my god 10 SECONDS!!) For a waiter/waitress to logout current user and log in with their own pin" or “so i would have to train my staff to never forget to logout after they are done with the tablet(in a discouraging tone)” and most staff or users in a busy place may tend to forget to do this. The only time i can think of when manager or owner will get frustrated that they used actual user pins, is when there is an mistake in a ticket and going back to the ticket shows not the original order taker but rather the current logged in user the suddenly that user gets blamed…
Yep in sambapos i have implemented this for many of my clients inside sambapos. Are you talking about the code that can be implemented into the module?
Like i mentioned. This isnt critical so you dont have to worry about it but just knowing this can be done and what code we can use to make it work is enough for someone to actually use it and apply it when they need it
You likely have not configured something properly in the config files and/or in SambaPOS.
Open up Dev Tools and look at the Console log for errors.
If you click on an error it will take you to the area in the code where something is “broken”, or it might take you to the Network Tab with the post/request/response selected.
Also look at the Network Tab to see graphql queries and responses if you don’t see any errors in the Console. Look for responses that contain error messages.
Copy/paste error messages here, or take screenshots and paste here so we can help diagnose the issue.
If you change or add certain things in SambaPOS you will need to restart the SambaPOS Messaging Server Service (use Windows Services to do this). Restarting SambaPOS will not restart the Messaging Service, so don’t bother trying that.
And sometimes you need to “force” a code-reload in your Browser with Ctrl-F5, which should flush the cache and reload the Javascript code.
Once you get everything working, restarting Messaging Server and code-reloads should no longer be necessary.
Your end-goal at this point is to get logged in and showing you the Main Menu.
This is perfect! Thanks for considering this implementation during your development. I wish i could learn as fast as you as to help contribute a lot more myself.
I appreciate the fact you considered my suggestions.
I just need help i knowing what query i need to use if i want to add department switching
Department, Terminal Name and Ticket Type is registered with the Terminal, along with the User (in this implementation, we use the the User that is logged in via PIN, not the Application User which is logged in with a Password).
So look at the queries having to do with Terminal Registration, like isTerminalRegistered(), registerTerminal(), unregisterTerminal().
Your best reference is to use the documentation in the GraphiQL interface. You will see in the documentation that you need all the parameters mentioned above to properly register a Terminal.
So if you want to switch departments, you need to unregisterTerminal() then registerTerminal() with the new Department (and associated Ticket Type).
Not sure if there is a query for getDepartments()… probably not, so you will need a Special Report using SQL to get a list. Take a look at how the other Special Reports are done to get an idea of how to make one for Departments along with associated Ticket Types.
