If any field returned by a REPORT SQL DETAILS:X
contains a pipe character, the data after that pipe will be displayed in the following field in the report.
I think you need to ESCAPE the returned PIPE character when parsing the ::{0}|{1}|(2) stanza in your REPORT generation code.
Any data after the pipe | is displayed in the following field, and if it’s the last field, an extra field is output.
Here is a sample report and output showing the issue …
What are you reporting that contains a pipe char?
There will always be certain charicters which are to be avoided, this is the same as with any coding.
Exactly the same as if you had a string containing both single and double quotes…
There will be a way arround this no doubt but this is not an issue with samba, the pipe char is used for defining columns.
As said what are you reporting which contains a pipe?
I intentionally allowed that so you can build report columns just inside the SQL without need of additional processing.
For a future update I have a todo item in my list to build reports without column definitions so column count will be determined from incoming data.
Interesting feature! I understand your desire to provide maximum flexibility and interconnectivity. I generally love that type of thing and is one of the main reasons I also love SambaPOS.
However in this case I am thinking you probably designed this feature prior to providing the web integration and might not have considered the data integrity implications of data being able to switch columns like that via a core function.
For example, it is worth considering what could happen if someone decides to use REPORT SQL DETAILS in the context of handling live data coming from unpredictable sources such as from a web service. It’s great that SP allows us to call web APIs! … but when doing any web integration we must take care that data isn’t able to jump columns based on it’s content otherwise a “description” column ordered before a “money” column could be constructed in such a way as to alter the value of transactions and cause serious havoc. Hackers love that type of thing!
We can work around this by using native SQL calls in script to do all the web interfacing and strictly avoid using REPORT SQL DETAILS for anything which might involve anything critical such as financial transactions.
Bear in mind though that developers need to be totally aware of this behavior.
I notice you don’t include a pipe character on the On Screen keyboard. It make sense to not allow users to enter a pipe into any text field, such as Ticket Note, TRANSACTION Description, or whatever, but when using a regular keyboard the pipe character is accepted unfiltered. I guess it isn’t likely a user will press that shifted key but if they do it, they could make some very strange things happen!
SP provides excellent user activity separation based on User Roles, Departments, etc. so i believe it makes sense to maintain the same data integrity and separation at a core level. With SambaPOS we can get very creative in our system design limited only by our imagination. It’s fantastic! Data integrity is essential for many applications so please consider it.
If people are already using this “live column delimiting” feature then I guess we are a bit stuck but if not, I strongly suggest removing that function and rely on the column definition syntax you have already implemented. In the meantime we can use script for any web integration (acting as a client to external web services) and avoid using REPORT SQL DETAILS for any data having text fields which come from user input or untrusted sources. It’s not a big issue for me now that i know about it but am rather concerned about other systems out there and the hacking opportunities this “feature” provides.
(V 5.1.62)
