WEBcnx 2023.1 is out now bringing with it a host of new features and performance enhancements. Read more.
A Job is the parent folder for all related tasks, documents, discussions & designs for a customers project. The user privilege to delete a Job therefore has the potential to delete ALL Jobs in the database. The privileges are therefore tightly controlled to ensure a user doesn't unintentionally delete more than they were expecting. A Job cannot be undeleted so you will permanently lose all data contained in that Job.
Note: Deleting a Job does NOT delete any Impact designs associated with the contents of that Job
If you already have the user privileges to delete a Job, you can do this in the same way you do for tasks. If the delete action is inactive (greyed out) then you do not have the privileges. You will need to contact your administrator to delete the Job or request permission to do this.
If you are unable to remember your password, you can request a password reset from the login page. After filling in the password recovery details, you will receive an automated response with a new password.
The exact infrastructure used for a WEBcnx installation is largely dependent on scale of use, any existing suitable infrastructure and preference. The following therefore should be used as a guideline, with further information supplied based on your proposed configuration.
The most common and straightforward configuration makes use of an existing Impact database server and mail server, and simply adds a new web server configured to run WEBcnx's various components. This web server would typically run WEBcnx, nServer and Licence Server and communicate with the databases and mail server through the Internal Firewall.
WEBcnx is very flexible in where the various component parts are situated and supports combinations from everything installed on a single server to each individual component being installed on their own servers.
Click to preview full-screen in new tab
Arden Licence Server is required by nServer, and is therefore typically installed alongside WEBcnx on the web server itself, and has no specific software or hardware requirements*. Should the use of an existing and/or separate Licence Server installation be desired, any network traffic would need to be allowed to flow between the web server and the alternate Licence Server host, as detailed in the relevant KB articles, here.
*Licence Server installations on physical servers may optionally utilise a physical USB dongle.
WEBcnx connects to the existing Impact database (via nServer) for user, customer, and design data, and to its own database for all task and WEBcnx specific functionality. These two databases are most commonly hosted alongside each other. This isn't necessary, but does simplify the resources needed and is therefore the recommended configuration.
The minimum supported database platform for Arden products follows the Microsoft SQL Server Extended End Date. See here for details. As each version of SQL Server Microsoft's products reach their supported end-of-life, Arden products will similarly cease to support them for subsequent product releases.
The WEBcnx plugin is installed on each Impact client computer to allow CAD users to access WEBcnx directly from within Impact. This enables Impact to interact with WEBcnx for actions such as creating and opening task linked Projects, as well as allowing the CAD user to update WEBcnx tasks, all without the need to open up their web browser separately.
The WEBcnx Document Extender is a utility that can be installed on each Impact client computer to provide CAD users with additional information about any WEBcnx references (aka 'Relationships') between documents and any tasks or Document type WEBcnx Custom Fields. Without this, users will only be able to see that a document has one or external references.
For information on Supported Browsers, please see here.
Our hardware recommendations are based on a customer's intended scale and nature of use, as determined by their site's configuration and the licensed WEBcnx modules. The following is also based on the assumption that the Web Server is to be dedicated to hosting WEBcnx, and that the nServer component is both installed alongside it, and is also dedicated to only WEBcnx specific usage.
*Concurrent user sessions
**For 3D layer thumbnail and Impact report template generation, and to aid LiveProof render performance.
Below, you can find the ports which need to be open/available for proper functioning of WEBcnx in a single site (non-Enterprise) installation:
The following ports are those most typically required for connection to a Microsoft SQL Server hosted Database:
Note. These port configurations are based on Arden Licence Server being located on the WEBcnx Web Server.
If you can't get as far as the login page, there's a problem with some part of your installation that is preventing the site from loading. This is usually caused by a fault in the site's web.config file.
500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.
The web.config has a section defined in the body of the file but is missing a <configSections> definition.
In the simplified example below, the <configSections> describes the expected Sections that should exist in the web.config. If one of those Sections exists but there is not a "section name" in the configuration section-handler declaration area at the top of the file (the bit between the <configSections></configSections>). In the example below, the Arden.WEBcnx.Workflow section is missing from the section-handler declaration are but it does exist in the body of the file.
<configuration> <configSections> <section name="Arden.Core.Data" type="System.Configuration.NameValueSectionHandler/> <section name="Arden.WEBcnx.Core" type="System.Configuration.NameValueSectionHandler/> <section name="Arden.WEBcnx.Site" type="System.Configuration.NameValueSectionHandler/> </configSections> <Arden.Core.Data> <add key="DataReaderReadChunkSize" value="65535"></add> </Arden.Core.Data> <Arden.WEBcnx.Core> <add key="PublicSitesColumnName" value="ST_PUBLIC"></add> <add key="nServerLogEnabled" value="true"></add> <add key="ApplicationName" value="WEBcnx Panther"></add> </Arden.WEBcnx.Core> <Arden.WEBcnx.Workflow> <add key="Enabled" value="true" /> <add key="WebRequestImpactConnectionName" value="" /> <add key="WebRequestWEBcnxLoginID" value="" /> <add key="WebRequestWEBcnxPassword" value="" /> </Arden.WEBcnx.Workflow> <Arden.WEBcnx.Site> <add key="DefaultImpactConnectionName" value="Demo"></add> </Arden.WEBcnx.Site>
There are two options for fixing this problem. If you're unsure what you are doing, please consult a member of the WEBcnx support team.
If the above solution has not resolved your problem, you may have found another cause of this error. Please create a support ticket and describe the problem you're having in as much details as you can. If possible, please supply copies of your web.config for analysis.
Whenever you view a webpage, you may notice the address starts with http (Hypertext Transfer Protocol). For websites that may use personal or sensitive data, such as your bank or other website you may log into, it's preferable to make these more secure by encrypting data transferred between the client (the web browser you're using) and the server (where the website is installed). This is done using a Secure Sockets Layer (SSL) that is configured on the server. Any website that is secured in this way will display https (Hypertext Transfer Protocol Secure) and display a locked padlock icon on the address bar.
As WEBcnx is an application that users log in to and contains potentially sensitive customer data, it is recommended that you secure it by applying an SSL certificate.
Depending on your needs, there are many different types of SSL certificate options available, all with their unique use cases and value propositions. The level of authentication assured by a Certificate Authority (CA) is a significant differentiator between the types. Each type of certificate requires specific information and documentation, and once that is received, a CA follows a set of Baseline Requirements to complete the certificate verification process before issuance.
There are three recognized categories of SSL certificate types:
Within these authentication types, there are also unique variations available including single domain, multi-domain, and wildcard. Which of these you choose depends on how you wish to configure your domain.
Depending on what type of websites, eCommerce or other web applications you may already have, you may already have an SSL certificate that covers your new WEBcnx installation. An existing Wildcard SSL certificate could be used if you wanted to host WEBcnx as a subdomain of your main corporate domain name; webcnx.yourwebsite.com for instance. If you don't already have any secure websites and are unlikely to need one in the future, a simple Single Domain SSL certificate is what you would need.
A single domain SSL secures one domain, both the WWW and non-WWW versions. It can also secure a single subdomain, hostname, IP address, or mail server. This variation is available in DV, OV, and EV authentication options. If your WEBcnx site is the only one you need to secure, you should choose this option.
Also commonly referred to as SAN certificates, multi-domain certificates allow a single certificate to secure multiple domains, including subdomains of a single main domain name or entirely different domain names. One of these can secure up to 250 unique domains with a single solution. They provide a convenient option for organizations that own a lot of domains and are looking for a simplified way to secure them through a single solution rather than purchasing an individual certificate for each. Multi-domain SSL certificates are available in DV, OV, and EV validation options. If you already host a number of secure websites or web applications with different domains, you may already have a suitable SSL certificate that can be easily extended to include WEBcnx. You should discuss with your IT team for more information.
The Wildcard SSL option is used to secure the main domain and an unlimited number of subdomains under the main domain. For example, www.yourwebsite.com, webcnx.yourwebsite.com, ecommerce.yourwebsite.com, etc., would all be secured with one Wildcard certificate. This type offers full encryption for the subdomains, making it an affordable and effective solution for most websites. They are available in DV and OV validation options. As for Multi-Domain SSL certificates, if you already have other secure websites, you may already have a suitable SSL that can be used. You should discuss with your IT team for more information.
There are a number of free SSL Certificate Authorities as well as those providing paid certificates. All types offer the same level of encryption, so a Single Domain SSL certificate of a Domain Validation type is just as secure as an Extended Validation, Wildcard SSL certificate. Free SSL certificates do not validate ANYTHING about websites, but just the ownership of the domain. On the other hand, paid SSL certificates verify the BUSINESS IDENTITY of the website before issuing the certificate to the site owner. It is an in depth verification carried out by the Internet certificate authority(CA).
If you're hosting WEBcnx for largely internal users who need to be able to access WEBcnx remotely, without having to join a VPN, a free Domain Validation certificate will do the job. If you may have your customers also accessing WEBcnx, an Organization Validated certificate will give them the added reassurance that the WEBcnx site they're connected to truly belongs to you.
A good rule of thumb is this: if the certificate is issued to a company, then it should be one that requires validation of that company – either OV or EV. And anytime there are transactions occurring on a website, an OV or EV certificate should be used to instil confidence in the customer that their data is safe and that they are dealing with who they think they are.
Changing a WEBcnx installation to use an SSL certificate requires changes to configuration files that can cause WEBcnx to cease to operate correctly. As such, this work should only be undertaken by a member of the Arden Software support team. Please contact us or raise a support ticket for further assistance.
WEBcnx is supported on three platforms - Desktop, Android and iOS. In the first two cases, the internet browsers are self-contained and automatically keep themselves up to date without the user typically needing to do anything.
Unfortunately, this is not the case on iOS. Web browsers on iOS are not self-contained, but instead use the engine provided by the Operating System. In simple terms, this means that while users can install Chrome or Firefox from the App Store and get access to those browsers' features, the actual rendering of websites is still done by Safari, the version of which is directly tied into the Operating System. This means that if a user is on an older device which doesn't have access to the most recent iOS updates, they will be incapable of upgrading their browser.
As such, at this point in time our browser support can be broken into two parts:
Since Desktop and Android browsers can be kept up to date regardless of operating system, rather than provide an official minimum supported version, we always recommend the most recent version. For whatever reason, if you are running an exceptionally old version of a supported browser, we will detect this at the point of login and inform you that you will need to upgrade (see Using Other Browsers below).
|2023.1 and above||Chrome, Firefox, Edge||Chrome, Firefox||v13.4 and above|
|2022 (13.0)||Chrome, Firefox, Edge||Chrome, Firefox||v12.5 and above|
|2019 (11.0)||Chrome, Firefox, Edge, Internet Explorer||Chrome, Firefox||v12.5 and above|
It is worth noting that while we have our list of officially supported and unsupported browsers, there is a long list of other browsers about which we make no comment. Many of these will in all likelihood work just fine, but we do not test against them and therefore cannot formally recommend them.
For example, there are several browsers such as Brave and Samsung Internet which use the same engine as Chrome, Edge and the Impact WEBcnx Plugin - i.e. Chromium. It's likely that these browsers - as long as they're kept up to date - will work, but any functionality, performance or styling issues encountered should first be replicated in an officially supported browser before being reported as bugs.