* IDEMPIERE-5450 Form SQL Process has security issues
* - fix javadoc
* - remove unnecessary code
* - minor improvement
* - improve discovery of single word commands
- avoids the need of space in the SysConfig key
* IDEMPIERE-5349: Adding AlwaysUpdatableLogic on Column and Field.
* IDEMPIERE-5349: Making Always Updatable logic to work when isAlwaysUpdatable is false and iAlwaysUpdatable made higher priority
* IDEMPIERE-5349: fixing error SP2-0027 in oracle
* IDEMPIERE-5349 : Fixing AlwaysUpdatableLogic not set when isAlwaysUpdatableLogic is null
* IDEMPIERE-5349 : renaming migration script and updatong AD_Field_V and AD_Field_VT
* IDEMPIERE-5408 Allow or enforce login with specific tenant (FHCA-3823)
- Add column AD_Client.LoginPrefix
* - Implement logic to manage login prefix
- Add SysConfig keys LOGIN_PREFIX_SEPARATOR and LOGIN_WITH_TENANT_PREFIX
* - Rename methods as suggested by Heng Sin
* IDEMPIERE-5408 Allow or enforce login with specific tenant (FHCA-3823)
For security reasons is better to ask for MFA before showing additional information from the user.
Refactoring the panels to show the MFA panel as soon as the tenant is defined.
* - Add uniqueness validations on tenant creation
* - Fix the Forgot My Password functionality
* - Fix the Change Expired Password functionality
* - minor javadoc improvement
- remove a redundant comment, the method is already mark as deprecated
Co-authored-by: hengsin <hengsin@gmail.com>
* IDEMPIERE-5439 Add unit test for Fact Reconciliation form
* Update WFactReconcile.java
* Update FactReconcile.java
Co-authored-by: Carlos Ruiz <carg67@gmail.com>
* IDEMPIERE-5438: Web Service Security > Access tab should allow to select WS roles only
https://idempiere.atlassian.net/browse/IDEMPIERE-5438
* IDEMPIERE-5438: Web Service Security > Access tab should allow to select WS roles only
Role with RoleType = null can also be used for WS, so must be included in available roles
Co-Authored-By: Carlos Ruiz <carg67@gmail.com>
Co-authored-by: Carlos Ruiz <carg67@gmail.com>
Fixes logic error in the way a user defined `jdbcUrl` in
`hikaricp.properties` is handled.
Additionally changed the default max pool size to the previous limit of
90 connections. PR #926 originally also had this but this apparantly
fell out. Testing showed that during first time server startup a flood
of connection can be made and a connection pool of 30 can be
overwhelmed and callers waiting on a connection will time-out.
* IDEMPIERE-5354 Manage use case for microsoft OAuth2 preferred_username (FHCA-3757)
* IDEMPIERE-5354 Manage use case for microsoft OAuth2 preferred_username (FHCA-3757)
* Replaced PostgreSQL and Oracle connection pools with HikariCP.
Replaced C3P0 with HikariCP. HikariCP is a Apache licensed connection pool with substantially better performance and better resilience to failure (DB disconnects, etc.) then C3P0. Read more about it here: https://github.com/brettwooldridge/HikariCP .
Cleaned up the `getCachedConnection` method. With HikariCP there is no need to retry to obtain a connection since getting an connection will block until a free connection is available or until a timeout is reached (default 30 seconds) at which point an `SQLException` is thrown. This also removed calling `Runtime.getRuntime().runFinalization();`. HikariCP is currently configured to detect / log leaks when a connection hasn't returned to the pool for longer then 5 minutes.
Loading of pool config properties was cleaned up. Defaults are now loaded from a single file instead of defaults coming from both file and hardcoded properties. It is now also possible to specify any HikariCP property in the user pool property file.
Initialization of the datasource must happen in the `getDataSource()` method because at object construction not all JDBC config is known. However this method could (as far as I could tell) be called concurrently from multiple threads but had no mechanism to prevent initializing the DB pool multiple times. The variable in which the pool itself was stored (`m_ds`) also was not marked volatile or immutable which could lead to visibility issues. Instead of lazy initialization of the pool in the `getDataSource()` method the pool could probably better be initialized at object construction. However I wasn't able to achieve that without breakage therefor I made the initialization mechanism work correctly with concurrent invocations.
Various config options such as the `MaxStatementsPerConnection` options were removed because HikariCP doesn't support them.
* (Re)added Sequence time-out.