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

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.  

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

To perform some house-cleaning for v11, we are considering removing the AudienceAgent endpoint. It doesn't appear to be used by anyone in the online environment, and therefore likely isn't by anyone in an onsite installation. Does anyone have any feedback why this endpoint should still exist?  

Dear Partners, This post is meant to inform you about some upcoming changes to our software that will greatly enhance your experience with appointment management. These updates, which involve new appointment fields, have been designed with backward compatibility in mind to ensure minimal impact on third-party integrations and existing functionalities. Here is a summary of the key changes: Appointment Description Field Update:  The existing “Description” field will be divided into two separate fields: “Title” and “Agenda”. Additionally, a third new field, “Internal Notes”, will be introduced. This division is part of our effort to make the appointment management process more organized and efficient. Text Table Field Changes: The  text  field length will be increased from 2047 to 4000 characters. A new  html_text  field will be introduced that will contain rich/HTML formatted text with unlimited length. Appointment Table Field Changes: New fields  agenda_text_id  and  internal_notes_text_id  will be introduced as foreign keys (FK) for text-rows containing Agenda and Internal Notes values, respectively. The existing  text_id  field will be repurposed as the FK for the text-row containing the new “Title” value. API (Service Layer) Changes: The Appointment carrier and the AppointmentEntity carrier will receive three new fields: “Title” (plain text), “Agenda” (HTML), and “InternalNotes” (HTML). The “Description” field will continue to exist for backward compatibility but will be a concatenation of the “Title” and “Agenda” fields. Note that if “Title” or “Agenda” has values during a Save-operation, any value sent in the “Description” will be silently discarded. If “Description” is sent in, but no “Title” or “Agenda”, the “Description” text will be split into “Title” and “Agenda”. Appointment Archive Provider, Find Provider, and Quick Search: These will provide the new fields (“title”, “agenda”, “internalNotes”) and the old “description” field, which will be a plain text combination of “title” and “agenda”. When the old “description” column is used as a restriction, a restriction handler should search the “title”, “agenda”, and “internal notes”. We believe these changes will streamline the appointment management process and improve overall user experience. The expected release for these changes are currently scheduled for v10.2.9 , likely releasing at the end of Q3 or beginning of Q4. Please feel free to reach out if you have any questions or need further clarification on these changes. Best Regards

The partnersites in SOD will be updated to Release 10.2.7 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.

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. We're working on this in SOD and will upgrade all partner tenants as soon as this is merged to our release fileset. Today we may move tenants to another build which enables this functionallity already (main), if you want to try this out early in SOD, please send me an email (appdev@ ).   We hope to be able to catch potential bugs during the summer, and are looking for messages in the console like the one in the below screenshot, please send info to bug (at ) superoffice.com