Hi,
We have been working on a new environment for a customer with a load of custom functionality, while developing this we tried to incorporate the new custom objects functionality as much as possible.
For example we use the default custom tabs based on the custom tables, but created screen choosers to our custom blogic screen for actual viewing and/or modification of the custom object records. This because there is a lot of custom business logic. This worked quite well because clicking a custom object row would just open an iframe to the 'old' blogic screens (and so the screen chooser strategy worked).
Only now we discovered with the update of the customer tenant to 10.3.8 that clicking a custom object row opens a new SCIL element instead of our own blogic screen. Since there is no way to incorporate any of our custom business logic in this screen (no save trigger, only load, no way to modify the screen layout, etc.), this won't work for this solution/customer.
What would be great if this depended on if there is a screen chooser for the custom object/table active. If there is a screen chooser active, just load it in an iFrame (behavior for now until 10.3.8), if there is no screen chooser active, use the new SCIL component. (Best of both worlds)
This way you can have the customer use the new functionality like selections, dashboards, custom tabs, but still have the flexibility for now to use the 'old' blogic screen for actual modification of custom object records. Otherwise, all these functionalities can't be used util the new custom objects have A LOT more functionality related to screen design, before/after save triggers etc.
I have asked operations to disable the CustomObjectsV2 feature toggle for this customer for now, with hopefully a solution like described here becoming available, otherwise we will have to revert back to the 'old' way of working with custom objects (creating custom screens for listing of records on company, project, etc., no selection/dashboard capabilities) since it is absolutely required here to have custom business logic when saving the custom object records.
All Replies (7)
Splitting the new SCIL element to a CustomObjectsV3 feature toggle would also be a great option to solve this..
Hi David,
Want do properly understand your pain points here, is it lacking save trigger or modifying screen. With current load trigger you should be able to manipulate values but if you have a need to drastically change how screen looks its another ballgame.
Hi Michel,
It is both, although the save trigger is the most crucial point so that we can have custom save logic.
The screen chooser still being used as the possible solution described above would be great, but if not possible/desired, then atleast splitting this new functionality to a new feature toggle (CustomObjectsV3) would be really helpfull. Then we can keep using our existing approach until additional options like the save trigger and customization of the screen layout within screen designer are available (and the customer can still enjoy new functionality related to selections and dashboard).
This was also the way it was segmented on the pilot page (https://community.superoffice.com/en/product-releases/pilot-programs/current-pilot-programs/custom-objects/)
Hi David,
We appreciate your feedback, and we will look into solutions for allowing to use "old screenchoosers" in combination with what is delivered for Custom Objects. Either we will try to detect if screenchooser is configured for Custom object or we will create another property on Custom object definition. I have to emphasize that this hybrid solution will not live forever, but until we are able to progress further in Custom Objects we do not want to throw to many curveballs at you.
We will also create Before/After save triggers for SCIL screen, and hopefully this will also help to move away from legacy solutions.
We are targeting getting this into 10.3.9 release.
Hi Michel.
That would be awesome! I understand that this a temporary solution until capabilties of the new custom objects have improved, but it will help us a lot in the mean time. As soon as the before/after save triggers are available we will start using these in combination with the new SCIL element where possible.
If this could be included for 10.3.9 that would be great, since that will also be the next OnSite release, which means we can also use this 'hybrid' approach at these customers.
Let me know if we can help with testing this or anything.
For those interested, both the screen chooser approach and the before/after save trigger of a custom object (when using the new SCIL element and not a screen chooser) are included in the 10.3.9 release.
Before/After save triggers for custom objects in SCIL
Support using Screen choosers in combination with Custom objects
I also are looking forward to the new version. I recently experienced the same problems as David for a custom object solution I built for a customer in June that stoped working as expected after the last upgrade. I have been worried since then but I now feel more relaxed since the next version is coming soon.
A lot of consultant have built quite advanced customer solutions the last decades and we are not afraid of having to rebuild things to make them work similar as before (and hopefully better). So just make sure we don't lose to much import stuff when you are buildning the new items in SCIL etc. We have all been able to do lot of magic tricks with our old service that we are not able anymore at the same level with components in new service/Custom object. Great customizatuons are often the things that will make our customers be happy and stay with us for a long time.