Global settings
| Administration Page | Application/Contract | Syracuse/Collaboration | Class | Settings | Representation | Setting |
|---|
| General settings | Authentication | Proxy settings | Mailer |
| License | History | Logs | Patch |
| Synchronization |
A pivot date must be provided to define the century used by default when the date is 2 digits. Only the upper bound is entered, the lower bound is calculated accordingly.
Example: If you enter "2029" for the upper bound:
1930 > is displayed in the lower bound.In this section, a default authentication setting can be defined for all users who have a "standard" authentication. The fields below have to be filled.
It can be "Basic", "LDAP", "OAuth2", or "SAML2":
The authentication method you select here is used by default but user-specific authentication methods always take precedence.
An LDAP server can be entered if the "LDAP" authentication is selected.
An OAuth2 server can be entered if "OAuth2" authentication is selected.
A SAML2 identity provider can be entered if "SAML2" authentication is selected.
You can define here the password policy to be applied.
When a user has a page containing a widget that accesses an external URL (such as www.google.com), the proxy settings of the web browser apply to allow or not the access to this external URL.
However, when a process wants to directly access an external URL, for example when calling a Web service, it is necessary to set up the proxy server to use. This section allows you to set up the proxy settings for the current Syracuse server. The information below must be entered.
If this check box is selected, a proxy configuration is used to access the external services.
This field refers to the administration reference proxy configuration used.
This section defines the default mailer used for notifications.
This section defines the default CTI service used for computer telephony integration.
This section allows you to enter a percentage value to apply to the maximum size granted by the license for a given period for Web service transfer. Every time this value is reached, a notification is sent automatically. The description of the notification is given on the following setup page for the license_web_warn record.
This section allows you to create technical trace files on request to send to Sage support. This section is available starting from version 2018.R3.
The first thing you have to do is set the maximum file size (10MB by default), the maximum number of files per day (5 by default), and the maximum number of days
(5 by default). In the default configuration:
The grid then allows you to select a level for each code to determine the amount of information you need in the logs. Five levels are available:
By default, all traces are stored in the logs folder for Syracuse. You can change this default folder in the nodelocal.js configuration file by changing the logpath attribute in the collaboration section.
Note: You can also create manual records for a given session by activating the session traces.
This section allows you to follow the modifications made by users in the MongoDB database over a period of time. For each modification to the entities you want to follow, a log displaying the modified attributes is created in the database.
The maximum number of days to keep history records. You can specify the number of days the history is kept in the database. After expiration, the history records are automatically deleted.
You can follow different groups of entities:
| Group | Description | Entities |
| authoring | Personalization | PageDef |
| collaborationArea | Teams, documents and storage, Office integration | team, document, documentTag, documentTagCategory, msoMailMergeDocSel, msoReportMode, msoWordTemplateDocument, msoExcelReportMode, msoExcelTemplateDocument |
| exportData | Export data | exportProfile, personalizationManagement, resourcePack |
| importData | Import data | importTool, x3UserImport, profileMenuImport |
| pages | Navigation : dashboards, vignettes, menus, pages | mobileApplication, mobileMigrateDashboard, mobileDashboard, mobileDashboardVignette, mobileGadget, mobileGadgetParam, navigationPage, landingPage, menuModule, menuItem, menuBlock, menuSubblock, menuCategory |
| statusAndUsage | System status and logs, maintainance actions | automate |
| technicalSettings | Setup servers, endpoints, schedulers and authentication | Globalsettings, localePreference, proxyConfiguration, ldap, oauth2, SAML2, notificationServer, boProfile, certificate, caCertificate, application, endPoint, host, x3solution, boServer, hrmServer, hrmSite, storageVolume |
| users | Users, groups, and role management | group, role, user |
The history log configuration entities are always logged, whether the technicalSetting group is enabled or not.
This block is used to set global variables. These variables are usually set automatically and we highly recommended that you do not change them manually.
Currently, variables are used by the Syracuse client to substitute placeholders in the url when opening a link.
Example: If a url is structured as "{$$CRMSite}/index.html", the "{$$CRMSite}" placeholder will be replaced by the value of the "CRMSite" variable.
Note:
This indicator is automatically updated by the platform. When set to "active", patches cannot be applied. The main reason is that a patch application is in progress, or that a follow-up step (such as the integrity check, triggered after patch application) is still running.
As this information is temporarily stored in the mongoDB database because node.js needs to be automatically restarted during these phases, the lock might remain set even if the patch application and the additional phases are finished. If this happens, the user can manually unlock the system by modifying this field. This has to be done carefully after having checked that everything is fine.
The information located in this block is related to future extensions for the platform (such as SData synchronization) and must not be modified at this time.