Hi @emre
After pulling my remaining hair out I realized that the importing of this screen is failing:
CustomerAccounts.zip (1.0 KB)
Any Ideas?
My concern here was this was part of 12 items (Rules, Screens, Script) so I need to know why it failed to have confidence in my process.
In the middle of cooking ATM family dinner but:
@emre it is not importing the Parameters section for the bottom command buttons such as it is not OVERWRITING the old screen.
Perhaps you can modify the bottom parameters screen and then IMPORT again? See if it takes the update? I know it should as the import file has the new parameters section…
No failure here. It imports command parameters fine.
To define your logic while importing on top of an existing configuration, you should use configuration tasks. Depending on your need you may want to delete existing screens or ignore if it already exists. Import functionality may skip overwriting some parts not to break an existing setup.
Hang on?
This is exactly what is happening I have updated the parameters by extending what is passed (added a few more) and this is not overwriting. So @emre you are saying this is by design?
I did not know this and it is very important.
Ok somebody help me out here - if I choose not to prefix or suffix rules I would expect they get overwritten with the new rule. That’s works ok it seems, so why would SambaPOS not overwrite screens?
EDIT:
Umm surely I or you Emre have not understood each other as I have imported 2 screens; (1)st just has a new Editor Widget and that worked fine; (2)nd Screen just had the Above “Command Buttons” parameters changed and that failed.
So I am lost to understand the logic and confused.
If you re-read your first post it says it fails to import. I understood it like it does not import so when I saw it imports fine I thought it is just a misunderstanding. Giving all details regarding issue is really important so we can communicate better.
Imports basically created for configuring new systems faster. Overwriting existing setups is something different. I hand typed a different overwrite logic for each importing item. Some of them may overwrite, some of them may not. This is not something random. It follows a logic but it is hard to remember without checking source code that works while importing entity screens. What I was trying to say you are not limited to my import logic if you use configuration tasks and suggested to use it in general.
Now I reviewed source code, imported your config a couple times and found it updates entity screens but just skips overwriting widgets. The reason of it is there is no good way to determine which exported widget corresponds to what existing widget as naming them is not required and uniqueness of them is not checked. Deleting existing widgets and creating imported ones is not a good idea as it will be a destructive import and we generally don’t do it. So if you mean to replace entity screen here it will be the safest to delete existing entity screen and recreate it with import to ensure there is no merging issue. You can do it with configuration tasks.
I can implement something to update named widgets but it is really not a good idea as it may lead to unintended overwrites and may create different issues on different cases.
fyi for next update I added a feature to update named widgets. If you properly name your widgets they’ll update fine.
I apologise for that as to me it was the best way to describe that issue. I have since renamed the topic.
Thank you @emre - so it was designed that way.
What I will do going forward is prefix all my incoming UPDATED logic; deleted the old logic and rename the new incoming such as Screens, Rules etc.
What would be good is if I new which objects I need to do this with? For example RULEs seems to overwrite no problems. What confused me is the 2nd screen was overwritten and a NEW widget was added. The issue is when a Widget already exists THEN I assume elements like name, parameters etc are NOT updated (reading above Widget is not updated)?
I have reviewed TASKS and the only information available is from kendash (to me of all people) and I feel due to time constraints I will carefully now manage my updates until I am fully trained on Configuration tasks.
Thank you - I think this will be a good feature and will produce results as expected by users.
OK while further testing it matching by name does not work fine… Should I just overwrite all widgets with imported ones when the imported screen have widgets ?
I would expect the entire Screen to be overwritten? Widgets, formatting, layouts etc. At this stage the only thing I can see not overwritten is the Widget Contents.
I assume because Samba allows for the prefixing of Imports that itself said “be careful as we will overwrite existing stuff so you might want to prefix it first!”…
That will decrease re-usability of imports. For example do you really want to overwrite screen layout you customized for your customer’s screen?
Pauln you will find basic config tasks are simple. yes custom ones can be more involved but you could build a config task the same way you do an import task almost… people are afraid of them but if you spend a fraction of the time you do trying to stretch limits of features you would see just how simple they really are.
If the Screen Layout was within the Screen as I see it then YES - if I import a screen I would want to import the lastest version with any adjustments.
When I say “within” I note sukasem talks about XML layouts which I am not referring to so this may be your issue that I am not understanding fully.
I didn’t understand if it is yes or no. 
YES - unless somebody else can provide a reason why we should not update the whole screen and contents then YES.
I cannot think of a reason to save a Widget especially when I have extended its functionality…?
Eventually for a large base of Customers YES. At the moment I am fine tuning a few Rules and Widgets for better flow and it is far faster to manager a LIVE system by importing the UPDATE. The reason why I have come to this Thread is I decided NOT to update LIVE but (as always just too anal) decided to test the import.
Did not understand why my shiny new Widget did not perform as expect in the office.
Ok so I will show you that it is just as fast since you refuse to try it 
BTW did you notice how familiar that select box was?
Well if I can speak for all us “average people” that is the first time I have seen “the process” - yes there has been lots of words but that came across as too much to do too little, to coin your fav phrase - “being honest here”.
Now speaking for myself, I try to read every post (I mean EVERY POST) so for some reason I have missed the steps you have shown above. Furthermore looking at the GIF it seems to IMPORT? Will we come up against the same issue as described in this post? Will Tasks overwrite Widgets?
Its not using the same logic as database tools import feature.
But lets just do a quick test and see. …
