Ok - I know you got this but have the same Widget on the incoming screen but change “say” command value or automation command name. See if the Widget is Updated with the new logic.
I was trying to use your own database but I dont have the updated one. So I am going to make an example.
Umm LIVE is now 16Mb after going live on July 20th. I can provide a new one next week after I have nuked the Data only…
Ok great - so the logic was modified to:
Customer Account=ZUCU_Wallets:EntityID={ENTITY NAME}-{ENTITY DATA:Full Name},EntitySearch={ENTITY NAME},EntityType=Customers,EntityCode=,AddOns={SETTING:Account Codes},RecordID=$1
This was not updated with manual import.
So here is how I wrote the task.
1st I delete the screen.
Then Step 2 you import the updated screen.
EDIT: I am going to see if I can get Layout View mode to inherent changes… It works fine for Custom Screen but layout mode we still have the issue of the actual widget being stored in the box on the left.
Yea - No, not sure what you mean here but that’s ok I think.
OK so dbo.EntityScreens holds all info including Widgets and the Widget Data such as command parameters.
I am going to demonstrate some more advanced stuff you could do to show how easy it really is. Right now I am playing with layout mode.
@Jesse sorry I mean to delete widgets not the entire entity screen as it may contain references to other parts of the software and it might be hard to update them.
1 Like
Ok I see what your saying so it should be done differently. hmm one sec. @pauln I will stop here then I do not have time this morning I literally have 5 more minutes. Configuration tasks are worth a look and they are not as difficult as they seem.
1 Like
Umm ok.
So here was my update to LIVE today:
5 RULES were updated in logic;
2 RULES were Added;
2 Entity Screens were updates (1 as above and the 2nd had a NEW widget which updated OK)
1 Updated Script
I keep a programmers journal of any changes and code them R,S,J with + or <> to represent a change or new addition.
As far as I can see the only thing that did not import was the EXISTING logic in a Widget as above).
The EXPORT process from Developer was simple, tick each item, create a Output File → copy to LIVE over RDP and IMPORT. Process for Adhoc Dev stuff only took a few minutes so good while in Beta stages.
@Jesse your amazing as always - yes the GIF took me back a bit (the Dark Force is calling me). Appreciate your time enjoy your day!
@pauln unfortunately there is not much resource about configuration tasks but I think that will solve your issue when you name your widgets. When you have time you can review existing configuration tasks to have an idea about that.
2 Likes
Ok so this will be in the next UPDATE or RELEASE? Just asking as unfortunately I am restricting my use of Beta’s due to not wish to implement new functionality and role a Beta to LIVE site.
Once my tinkering is done I will test every corner of the beta (Standard Samba) in respect of any feature I have requested or new ones within my skill set.
EDIT:
Was freaking out for a moment then @emre as I thought I had not Named “that Widget” - but yes it has a name “SWD_Customer Accounts”
fyi @Emre. other limitations with Export/Import i found recently:
-
Import Printer loses the Share name content
(the dot used for Task Printer share name in Kitchen Display was lost when importing). -
EntityType import loses some Custom Field configuration parameters.
In my case i am storing system logic options in Entities and using Value lists for those, such as Yes,No … Always,Never …stuff like that. The field names and value lists looked as if they were imported fine, but when editing an entity of that type, the value lists no longer activated the list control when editing the entity. I had to recreate the Entity Types and options sets by hand in the target db. -
I often get error “Sequence contains more than one element” when importing rules and actions, even though the names chosen are all unique. Merging updates into the target db typically takes hours of dividing the rules into small groups for export and importing those group by group to eliminate the “problem” rule by trial and error. But the rule(s) causing the error appear to be fine including the actions within them, and they run fine on the source db.
I hope this feedback helps smooth out limitations with Export/Import.
To workaround these problems I would love to know how to use Configuration tasks. I can start by looking at some existing Config Tasks, making guesses and experimenting, but we really need some documentation on it
2 Likes
Further to the Entity import issue, it appears that the import of a group of entities can cause corruption to existing entities which were not members of the import set.
I came to this conclusion after diagnosis and repair of a weird situation whereby {REPORT ENTITY DETAIL:X} was not returning the data contained in the Custom Fields. The report tag returned Null/blank data. This only occurred with specific entities and the data in those entity fields was verified to be correct numerous times using both the batch editor and the single entity view.
After recreating those few entities from scratch and populating with the exact same data, the reporting tags and all automation which depended on that data worked fine thereafter. It’s worth noting that while the fault was present, other entities used in that context were working fine. No automation was changed from before to after.
This strange behavior started the day after I had merged some new entity data using the import tool to update entities of a different type totally unrelated to the features I had upgraded.
After spending a couple of hours debugging this, I now have a policy to not import entities! At least until the import code is reworked. Hopefully Emre will discover the cause of this issue when next revisiting that import code.
Configuration tasks could be the way forward but haven’t used them yet.
1 Like