The partnersites in SOD will be updated to Release 10.2.11 monday morning around 06.00.  The version is still under development, so the sites will be updated ever day when there are any changes, until the release is out.

In the worst-case scenario, an application may have hardcoded a tenant API URL as "https://online.superoffice.com/[Cust00000]/api/v1," which may currently be functional. However, we have consistently advised developers to use either the WebApi_Url or NetServer_Url, which are issued as claims in the OpenID Connect id_token. In light of upcoming infrastructure changes aimed at improving load balancing and performance, the API URLs for online tenants are becoming more dynamic. The plan is to remove the API URL claims from the id_token and now are recommending all applications use the state URL to retrieve a tenant's API URL. The state URL follows the format: https://[environment].superoffice.com/api/state/[Cust00000] Here, the "environment" parameter is set to either " sod ," " qaonline ," or " online ," representing development, stage, or production environment, respectively. The "Cust00000" parameter is the unique identifier for the tenant. How often should applications check the state URL for changes? API URLs will typically be invalided during the evening during maintenance, which is posted on status.superoffice.com, however it may also depend on how much traffic an API endpoint receives. For more information, please refer to the documentation available at: https://docs.superoffice.com/en/apps/tenant-status We plan to enable these changes in the SOD environment moving forward. This will allow you to test your applications' resiliency and ensure it continues to function and operate before pushing any required changes to production. We expect to roll out these changes to production on November 17th . Question and/or comments are welcome.

Trude recently posted an announcement on the Web Application Product forums that SuperOffice Onsite v10.2.9 is the last version to support PageBuilder customizations. Any thoughts on this matter should be in reply to her original post (OP).  Best regards.

The partnersites in SOD will be updated to Release 10.2.9 tuesday morning around 06.00.  The version is still under development, so the sites will be updated ever day when there are any changes, until the release is out.

Anyone using the MassOperations API ? In NetServer Core, this is located in SuperOffice.Data.Dialect namespace, SuperOffice.Data.Dialect.MassOperations . In NetServer web service Agents, it is facilitated by the DatabaseTableAgent endpoint With the introduction of freetext indexing on udef string fields, this has proven to have a negative impact on MassOperations performance.  A recent scenario highlighted the impact when performing an Upsert operation, uploading four thousand rows with one or more user-defined fields, went from ca. 4 seconds to 3 minutes. This performance degragation only occurs when udef string fields are used. Extra fields have no affect. Question : will this affect your apps or integrations? Best regards.  

As of yesterday we introduced the support for TLS 1.3 for all endpoints in sod.superoffice.com (developement) and qaonline.superoffice.com (stage). This means we support both TLS 1.2 and TLS 1.3 on public endpoints in these environments now. If you have any issues in SOD and Stage after this, please contact us

The following Save validation rules will apply soon (v10.2.7 or higher): Valid number are not blank/unique according to Number allocation options . ContactEntity Name is not null or empty Number2 field is valid PersonEntity Contact property is not null Must have one: first, middle or last name PersonNumber property is valid ProjectEntity Name property is not null or empty ProjectNumber property is valid SaleEntity Heading property is not null or empty Number property is valid Note: when following best practices the Number properties are always populate correctly.  

The partnersites in SOD was updated to Release 10.2.8 this morning around 06.00.  The version is still under development, so the sites will be updated ever day when there are any changes, until the release is out.

This article is about proposed internal refactorings in NetServer. If you have onsite code that includes NetServer in-process and uses or contains code that refers to ISoDataLookup or BeginIgnoreSentry , then this is for you. If not (for instance because you only work with our Agent API or Online), then read out of interest, or spend your time elsewhere. The several ways to Ignore Sentry Sentry is the data access control mechanism in NetServer, and it is deeply connected to our database layer. Access control is not something application developers need to remember; it’s something that is always there. But sometimes there is code that acts on behalf of the system , not the particular user. For instance, when a Dynamic Selection is completely enumerated (all members fetched), we write that member count to the selection row; it’s a useful thing to track. And this should be done even if the user only has read access to the selection. For just that operation, we want to turn off the access control; this is what IgnoreSentry means. In other cases there is a whole block of code, multiple database accesses, that needs to turn off the access control. And, not least, when the Sentry code itself needs to look at a database field value to do its access control calculations, it needs to not trigger itself recursively. Each of these IgnoreSentry scenarios has its own mechanism. They have evolved over time and (among other things) are not compatible with async/await. They also consume more CPU cycles than we’d like. The big refactoring TL;DR: We are going to combine instance-dependent IgnoreSentry (implemented through  ISentryIgnorable), data lookup IgnoreSentry (implemented through ISoDataLookup) and code-block IgnoreSentry (implemented through ThreadManager static methods) into one common system. The exact details are not 100% clear yet – it’s complex, critical, hot-path code and we will need to evolve the refactoring iteratively before we know the answer. We will attempt to minimize breakage, but there is probably going to be some impact. Timeline and feedback These changes will be released either in 10.x, or in 11.  For us it would be most convenient to include them in some 10.x version, as and when the coding is done. But it depends on the impact on the community. Note, however, that such impact should be limited to partner code that actively uses these mechanisms. We believe that there is little-to-none such code out there… and this is your chance to enlighten us. Does this sound familiar? Have you written sentry-related code, IgnoreSentry, anything related?  Do tell!

At SuperOffice, we greatly value our ongoing partnership and collaboration with you. As we move forward on our journey to enhance and streamline our services, we wanted to provide you with an important update regarding our SOAP support. While we understand that not all of our existing partners and integration customers will be able to make an immediate shift away from SOAP, we want to share our desire to gradually eliminate SOAP support within the next few years . This transition is part of our ongoing efforts to modernize our platform and enhance the overall experience for our users. Our SOAP offering comprises two key components: the SOAP proxy client and the web service endpoints . SOAP Proxy Client - SuperOffice.NetServer.Services: Our SuperOffice.NetServer.Services package , which includes the SOAP proxy client for communication with SuperOffice WCF-based SOAP web services, has played a vital role in our journey thus far. However, we have observed a significant decline in its usage since the introduction of the RESTful-based proxy client, SuperOffice.WebApi . These two clients offer nearly identical functionality, with SuperOffice.WebApi adopting a RESTful protocol approach. While there are some nuanced differences, detailed information is available in our SuperOffice Docs .   Migration Status: We are pleased to inform you that all SuperOffice applications have either completed their migration away from using the assemblies within the SuperOffice.NetServer.Services package or are currently in the process of doing so. This transition has also involved the move from .NET Framework to .NET Standard 2.0, where we replaced legacy NETFramework 4.8 WCF dependencies with CoreWCF. Eliminating SOAP Support: As part of our ongoing efforts, we have a strong desire to completely eliminate our SOAP offering when SuperOffice reaches version 12 . While we acknowledge that this transition may not be immediate for all partners and integration customers, it represents our vision for the future of our platform where we would like to offer services in alignment with current trends. Your input and feedback are of great importance to us, and we believe in fostering a collaborative environment where your insights help shape our decisions. We understand that change can be challenging, and we are committed to supporting you throughout this transition. We encourage you to share your thoughts, concerns, and suggestions with us. Your feedback will be instrumental in ensuring a smooth and effective transition away from SOAP. Thank you for your continued trust and partnership with SuperOffice. Together, we can embrace this evolution in our technology stack and continue to deliver exceptional solutions to our customers. Should you have any questions or require further information, please do not hesitate to reach out to us. Best regards