I’m currently moving from V4 to V5 and I’m doing some cleanup. I’ve just re-setup “reopen closed tickets”, however the automation command button is not enable (grayed out) no matter what I do. Its visible, so I’m not sure what is wrong with the mapping at this point. Any ideas?
After reading further I removed the * from “Enabled States”, as per a post from Emre. In V4, enabled states had a * in it. Now it works, is there any reasoning behind this?
I think it may be related to the isclosed option.
1 Like
Very interesting! Thanks for pointing that out.
This is a good example of why all Actions need to be thoroughly documented, together with all automation quirks.
This particular anomoly is related to the ticket “IsClosed” state/mode. The Automation Command Button behavior in this mode is inconsistent with normal expected behavior and hence can cause a lot of confusion.
I think this shoud be treated as a BUG. (i.e. undesirable and inconsistent behavior which can be corrected with C# logic handling.) It’s an “edge case” which should be specifically detected and handled to create consistent decoding of mapping syntax/symbology.
Instead of relying on the suggested workaround (Enabled States mapping is set to blank instead of * ) the C# code should detect the ticket IsClosed mode and change the button mapping decoding behavior accordingly.
It is not a bug and it was by design. It lets you enable automation for tickets not closed but won’t work for tickets that are marked as closed. Leaving it empty makes it work on all tickets even marked as closed tickets.
You are missing something that is what really makes Sambapos special and it was by design. You may never see a fully documented layout of every action or rule etc. The reason is Emre purposely allowed us to use them in various ways he didn’t even think of. He wanted to allow this. It was not a bug. This is what made Sambapos what it is today. And it’s partly why Emre always said that it was the community that built Sambapos.
i understand what you mean. But if the “design” is confusing and can be improved by changes in C# code, what do you call that scenario?
What is a “bug”, “feature”, or “by design behavior” is flexible terminology within a s/w development environment.
By “bug” i mean … the C# logic is such that it causes confusion and should be changed. I wouldn’t call that a “feature” because such improvement maintains consistent behavior, it doesn’t extend it.
So your suggestion is to introduce a change that will break just about everyones setup ?
Is it confusing or is it different? Yes it needs to be learned but it’s mostly just different. It’s not really confusing.
No. I think the C# code can be made to enable the button when either a blank or asterisk is specified so it doesn’t break any existing setup. Or is there a specific scenario where that logic wouldn’t work?
I use this feature myself to enable automation commands only for non closed tickets with any state. It’s a simple feature. Just put a * very easy no other logic needed. If I want to enable it for all states on even closed tickets just leave it blank. That’s an easy solution.
I don’t think your understanding what I’m saying.
If that coding is REALLY needed to support some other edge case then the “documentation about mappings” needs to mention these edge cases.
There is great documentation but it will never be able to cover everything. Your never going to get a comprehensive manual. We are getting some very good resources though and it will grow.
You simply can not document every use case. It goes against Sambapos nature. We discover new ways to use features all the time.
Btw it is documented in the forum. I believe I read a post where Sukasem explained it well.
We overlapped our posts timings there.
About the logical use of a blank mapping you just mentioned would be very EASY to document under the “How to use mappings” section.
I understand resources need to be rationed and that’s because of economic constraints. And those economics depend on market penetration, and that depends on user experience and ease of config, and that depends on documentation, and that depends on having enough resources.
Justifying the existing limiting circular condition and rejecting improvement suggestions by the idea “You’re never going to get a comprehensive manual” is not helping break out of it.
Having used and written technical documentation over decades, it is abundantly clear to me there are practical approaches and straight forward ways to document the automation system of SambaPOS. (This is moving into a subject for a different topic)
As I said we have a great knowledge base that is growing constantly. You won’t find a comprehensive manual though. New features are discovered constantly that were not specifically designed.
You have me all wrong. I never rejected anything. But this was not a bug. Yes we should probably document this I agree.
We are not trying to break out of a cycle. We are growing and expanding rapidly. Great things are happening.
Good! and I can see new sales expansion opportunities opening up. I also observe and can readily predict that those new opportunities will be deeply hampered if the “proper technical documentation job” is treated as low priority and you continue to believe the forum is an adequate source.
By “proper technical documentation” I don’t mean end user step-by-step instructions stuff. I mean documentation written for a moderately technical audience … things like lists of actions, rule conditions, action constraints, valid syntax, valid context of TAGS, all properly structured with details and interlinks.
Just look at documentation of almost any massively adopted development platform or API for ideas on how it could and should be done. To get anywhere near to that level of mass market acceptance you need to strive for that level of excellence.
There are various limiting factors including the need for clear and elaborate technical documentation which is glaringly obvious to any experienced s/w developer. But there is some kind of embedded erroneous ideas that “it can’t be done”, or “just search the forum” which is holding you back from reaching the potential of much larger scale use. Other technical aspects also need resolution but this is a core weakness.