Global settings
Administration Page | Application/Contract | Syracuse/Collaboration | Class | Settings | Representation | Setting |
---|
General settings | Authentication | Proxy settings | Mailer |
License | History | Logs | Patch |
Synchronization |
You need to provide a pivot date to define the century used by default when the date is two digits. Only the upper bound is entered, the lower bound is calculated accordingly.
Example: If you enter 2029 for the upper bound:
In this section, you can define a default authentication setting 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 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. You must enter the information below.
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:
The Patch system locked indicator is automatically updated by the platform. When set to active, you can't apply patches. The main reason is that a patch application is in progress or a follow-up step (such as the integrity check triggered after the patch application) is still running.
This information is temporarily stored in the MongoDB database because node.js needs to be automatically restarted during these phases. So, 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 unlocking has to be done carefully after having checked that everything is fine.
In the Update expiration period field, enter the number of days to keep the ZIP file in the update entity. After this set number of days, the ZIP file is removed from the MongoDB database, but the record of the update entity is kept. This removal allows saving space in the database.
If the value is 0, the ZIP file is kept.
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.