Hi, One of our customers has a custom screen built in Service. First, the user uploads a .csv-file, Then, they click "Upload" which executes a CRMScript and redirects them to another screen. The CRMScript parses and saves the csv data in an extratable. The data is then displayed in another Screen using a static table.  After confirming that the data is correct, the user click "Import" which executes another CRMScript. This script contains some business logic and calculations, some of the data is saved again to another extratable.   We're encountering an issue where users sporadically receive the error message below. The error message usually appears instantly, rather than after the script has been running for a while.  Script is taking too long to execute. Execution time: 1066117.28,  User CPU time: -6871.58 After retrying 3-4 more times, it works without any issues. Does anyone have any idea what could be causing this error? Not sure if it helps, but i've also seen the error occurring in other customer's enviroments when custom screens are loaded. Let me know if you need more details.

Hi forum I have a customer running the SCIM integration, and they are asking for some more information on the specifics of how SCIM handles retired users, and users who just had their user plan revoked. I explored the SuperOffice documentation regarding SCIM (System for Cross-domain Identity Management), but I couldn't find specific details on when a user synced from Azure AD to SuperOffice via SCIM is marked as retired/deleted, or when their license is simply removed without the user being set to retired (By being removed from the userplan AD group, but staying in the group specifying role and group). Unfortunately, the specific scenarios i am looking for does not seem to be covered in the documentation. Example ruleset for my SCIM configuration: License groups in AD: so_salesprem //Provides access to Sales Premium so_marketing //Provides access to Marketing so_serviceprem //Provides access to Service Premium so_salespremservicepremmarketing //Provides access to the full plan Role groups in AD: so_role_0 //Sets the user up with role 0 so_role_1 //Sets the user up with role 1 Primary groups in AD: so_group_management //For the users in the management so_group_sales //For the users in the sales department so_group_marketing //For the users in the marketing department A typical user will therefore be assigned three groups in AD, depending on what we would like them to end up with in SuperOffice The SCIM configuration will then have the following rules: In AD Group so_role_0: Primary group - Always: Fallback group In AD Group so_role_1: Primary group - Always: Fallback group NOT In AD Group so_salesprem: Plan - Always: Not selected NOT In AD Group so_marketing: Plan - Always: Not selected NOT In AD Group so_serviceprem: Plan - Always: Not selected NOT In AD Group so_salespremservicepremmarketing: Plan - Always: Not selected In AD Group so_role_0: Primary group - Always: Fallback group In AD Group so_role_1: Primary group - Always: Fallback group The above rules are their to provide default settings, if the AD user does not meet any other rules, like those defined below: In AD Group so_salesprem: Plan - Always: Sales Premium In AD Group so_marketing: Plan - Always: Marketing In AD Group so_serviceprem: Plan - Always: Service Premium In AD Group so_salespremservicepremmarketing: Plan - Always: Sales Premium - Service Premium - Marketing In AD Group so_group_management: Primary group - Always: Management In AD Group so_group_sales: Primary group - Always: Sales department In AD Group so_group_marketing: Primary group - Always: Marketing   My tests are the following: For a user that is decommisioned/retired in AD, the following happens: User is marked as retired, and license is revoked. This is what i expect:  User is marked as retired, and license is revoked and made available for other users. For a user that is NOT decommisioned/retired in AD, but having their license group removed, keeping the two others, the following happens: User is ALSO marked as retired, and license is revoked and made available for other users. This is what i expect: License is revoked, and made available for other users   Is this the correct behaviour? How would i setup SCIM rules to make sure a user is not marked as retired just because of loosing it's license plan?   

Hi,   In the Swagger file of the Agents Web API, the "MemberCount" property, that belongs to "SuperOffice.CRM.Services.SelectionEntity", is defined like this:   "MemberCount": { "format": "int32", "description": "How many selectionmembers (for progress bar calculations) - estimate, -1 (or 4294967295) means we don't know", "type": "integer" }   4294967295 is the max value for an unsigned integer. Obviously, -1 cannot be assigned to an unsigned integer, so there is some inconsistency regarding the intended data type here.   In package SuperOffice.NetServer.Services.10.2.9.778, SelectionEntity.MemberCount is declared as an unsigned integer:   // // Summary: // How many selectionmembers (for progress bar calculations) - estimate, -1 (or // 4294967295) means we don't know [DataMember] public virtual uint MemberCount { get; set; }   And indeed, when we make a REST call to the Web API, we receive UInt32.MaxValue as the MemberCount for selections with an unknown number of members:   ... "IncludePerson": 0, "MemberCount": 4294967295, "Name": "DataBridge 20170705143636 new person", ...   The client we generate using OpenAPI Generator declares SelectionEntity.MemberCount as an int, so it crashes when it tries to deserialize a selection with an unknown member count.   JSON integer 4294967295 is too large or small for an Int32. Path 'MemberCount', line 1, position 973.   The only way to get OpenAPI Generator to declare MemberCount as a uint is to add a flag --openapi-normalizer ADD_UNSIGNED_TO_INTEGER_WITH_INVALID_MAX_VALUE=true and change the Swagger file as follows:   "MemberCount": { "format": "int32", "description": "How many selectionmembers (for progress bar calculations) - estimate, -1 (or 4294967295) means we don't know", "type": "integer", "minimum": 0, "maximum": 4294967295 }   Can you let us know if you are able to automatically add the minimum and maximum fields in the Swagger file? We would like to avoid having to change the Swagger file manually as much as possible.   Thank you

Hi guys I'm having a problem with a customer running an old SO 8 instance, without maintenance agreement active.  As you can see here, license is active until 2099.   The problem is, that all modules using the ADO com Database API has stopped working recently, returning the message: The license has expired and the SuperOffice API will not allow log in. Renew the license using soadmin.   Everything works, SO Web, Service, SO Win etc. But if i run any Amesto apps for example, i suddenly get the above error. If i create a simple shell script like Set DB = CreateObject("SuperOfficeDB.Database") If IsObject(DB) then DB.Login "xxxx", "xxxxxxxxxx" Set con = DB.GetContact(1) MsgBox "Contact Id 1, Name: " & con.Name else MsgBox "Unable to connect to database" end If Set DB = Nothing I get the same error.   I thought it wouldn't make much sense to ask support about this, before some of you could maybe point out what specific license it is they are missing, cause from what i can tell from the admin interface, everything's fine?   Thanks in advance.

As of the documentation I gathered that calling of a crmscript  including its Key it should be accissible publically and the script should handle the auth process internally https://sod2.superoffice.com/Cust*****/CS/scripts/bLogic.fcgi?action=doScript&includeId=getTids&key=SECRET the request works only when I am logged in but is being redirected to a Login page when not.

Hi, Is there any support for ApplicationIntent=ReadOnly in the REST API? For example in the connection string for the web config: I've tried several variants here, but nothing seems to work.   We could really benefit from this seeing as our environment is running on a SQL cluster with a read and a write node to balance load, and we have a lot of integrations using the API 24/7. It's worth mentioning that we have completely separated the API to its own server, so changes to the web config here will not impact the rest of the installation.   Thanks!

Hi all, We have realized that we need to introduce some limitations to the CRMScript tracing functionality. This is a result of the following problems: Tracing is enabled and then forgotten (it does not disable automatically). We have seen traces from 4 years ago. Tracing is enabled for scripts that are executed every minute, causing lots of rows in the script_trace_run table. Tracing is enabled for scripts that generate lots of trace data (e.g. tracing inside tight loops), causing large blobs in the script_trace_run table. In total, this has become a resource problem, and we need to introduce some limitations. We realize that tracing is an important tool for developers, so we would like to do this in a way that minimizes the negative impact. I am writing this post to get some feedback from you. Here are some ideas we have to remedy this problem. Please tell us what you think: A trace is automatically disabled when it has created X number of script_trace_run rows, or Y amount of script_trace_run data. Perhaps X will be 1000 and Y will be 100MB. We reserve the right to change these numbers until this is not a problem. We can introduce a new flag for a trace: Only save if exception is thrown or a new keepTrace() function has been called inside the CRMScript. This allows you to enable tracing for a script, but it will only save a trace-run if something interesting happened (either exception, or your own logic evaluation that tells you you should keep this trace).  We can introduce a new feature where you can add an email address to a script-trace to be notified when a script-trace-run was saved. Will only alert once, until reset. Sverre