So I am considering storing system settings such as; Happy Hour Start/Stop Days & Times; Reward Points to Dollar conversion rates and so.
We know by using ACTION:Update Program Setting we can store a settings, and we can use {SETTING:Variable} to access the variable.
So what if we wanted to not hard code the Variable “Values” in rules to make SambaPOS more portable?
Firstly: can the ACTION:Update Program Setting - read a Variable like {ENTITY DATA:Configuration.ConvRate}?
Secondly: would we use an Custom Entity say “Configuration” 1 flat Record OR 2 field variable using Field Name (Convrate) & Field Value (250)?
Lastly:, how would we edit the data? Custom Editor Widget like “Ricks” or “Q”'s Z-read Screen?
This exact thought has cross my mind a couple of times.
As far as I see you are using an action to update the program setting, so long as you have a valid {tag} it should work in a program setting update action.
I asked a very similar question a while ago, pretty much the best way to achive a custom manager/admin/config screen you would want to use a custom entity screen. This to be fair would give you a pretty blank canvas to do all sorts.
Automation command button to a [?SettingA] prompt, ask question options for multiple choice, toggle value commands just to start, not done a huge amount with custom entity screens but would be nice if a label or something like that would be able to read the value so you can set up so you can see current settings etc.
Given the setups in the examples you have mentioned I imagine there is many many ways to do all sorts of nice things.
My plan before understanding configuration tasks was to make a ‘ultimate’ all in one setup and enable/diable feature but now see the better way would probably be to just ‘install’ the parts of the setup with config tasks.
Yes thought you would be first to chime in considering the number of site s you have been working on
Well you raise a valid point @JTRTech - maybe the way I should be looking at this is a Configuration Task to change these settings? I can see kendash twitching over his “pulled pork” cook at the mere thought of a configuration task! lol
But still we need to enter the value somewhere and would need to change them for each site like “no happy hour on Saturday” or even just “no Happy hour”. The [Day Constraint] may be an issue as I never seen a {TAG} used in a Constraint?[Edited] - Yes I think you can, always refer to Qmackay’s VIP Tutorial, just so much in it!
I am thinking 1 record flat file for new Configuration Entity. Like you would use it “outside the ticket” (!!! learnt a new term today, head still hurting from a thread with kendash ). Given its outside the ticket there is no record positioning.
Missed that one… guess it was like the 100 post back and forth I skipped through on break at the day job LOL
My plan was a little different to yours from how I read it.
I was thinking enable/disable features depending on the customer needs but got the impression you were looking for a non-admin way to set the values for your setups like happy hour times and days etc.
I think for that you would be better of with a manager entity screen with the settings.
Although might be misunderstanding your definition of ‘portable’
Nope - your spot on, we are thinking the same. Just had a moment about configuration tasks to see if they could be incorporated somehow. Management Automation Button - YES, just to edit system systems which affect settings in Rules and their Constraints.
[EDIT] Removed next line following discussions. Maybe a feature request? What did @emre say when you discussed it last time?
We have execute configuration task action. Config tasks can do just about anything. They can ask for input, ask to enable or disable things, can ask to customize things. It’s almost endless.
Are there you go! knew kendash would smell a configuration task…
Just kidding I think this would save just another Enitity and associated screen saving more “bloat”.
Ok, done I think @JTRTech I may try to head down this path as ultimately we will need to have this skill to deploy our current feature set, but more importantly new feature sets as we create them.
Well worth the discussion, Gents, thanks.
Now where is that documentation on configuration tasks
It was custom entity screen and configuration tasks as options.
My opinion was for enable/disable/install would be config tasks.
The ‘manager’ non admin settings for regularly changed things, possibly happy hour times/days where manager can do but dont want him/her changing rule constrains etc entity screen would be preferable.
I liked that method as also should allow clean display of current values with then a button to change options.
The non-admin manager type ideas generally dont get such a great response/interest.
My aim being allowing a ‘safe’ way for a customer/manager who isn’t fully samba trained to update certain settings without being and admin able to mess up rules etc. This is why I was trying to push for things like the ability to seperate product and menu settings from automation etc as a manager should be able to update products etc but you dont necercerally want him to be able to mess with the automation and screw things up.
For enable/disable config tasks probably best and for my plan I intent to restructure the rules to be more indpendent of each other as to date have generally preferred to keep rules streamlined with many actions so it is easier to visulise the flow however this makes but when it comes to reselling/multiple systems it would be better to have individual config tasks for the setup components ie happy hour, room accounts, switch user, fast cash etc and you can just run the config tasks on system build and create setup to order rather than at the minute what I do which is a medium general setup which I add / remove settings on demand.
You actually made me burst out laughing! Private joke: I going to Yoga tomorrow just to chill out, if I get stuck into your time clock task I will need to sit in a bucket of ice! But have no fear I will get to it, just after a few more Yoga sessions…
Yes can’t get past this point. When I get to creating tasks I will look from this point of view, seeing if they can be segregated and cut down to small bits like: “Change Happy Hour Days…” or “Change Points Rates…”. If they can then been kept in a Managers Section, then maybe, it can suffice.
What sort of permissions can be assigned? Like this set of configuration task are Super User; this other Set Manager; and this last set User? Also can they be placed on individual screens or just turned On/Off depending on access level?
The tasks them self can’t be done that way. But if you use entity screens with various methods to execute tasks you can map access to those screens.
I already mentioned we have execute automation task action. So it could also be automation command buttons in tickets with state visibility restrictions. I mean it’s an action so you imagine the automation you can do.
). Given its outside the ticket there is no record positioning.
