* feat: installation config in super admin console
* Added the ability for super admins to view, edit and update
installation config values. Also they can add new isntallation config
values. The impact of editing and adding depends on which all
installation config values are being used in the code.
* Known limitation now: Ability to edit hash values (for eg: feature
flags) are disabled. This requires more work and will be taken up in
a secondary set of changes.
* Minor UX improvement. Clicking on the Sidekiq option in the super
admin siebar will now open the sidekiq dashboard in a new tab rather
than in the same tab that you were using super admin.
* fix: method name fix in custom adminsitrate field
* feat: added locked attribute to global config
* Added the locked attribute to instalaltion config table. Added
necessary migrations. Added changes in config loader.
* Added the changes on the installation config yml
* Locked the account feature defaults in code
* feat: show only editable configs in admin console
* Added a new scope in installation config model
* Added scope in adminstrate controller for installation_config
* fix: new installation config create error
* Fixed the error in new installation config create
* fix: specs coverage
* Added specs for installation config super admin controller
* chore: update git ignore with encrypted config ext
Automate conversation display_id generation with db triggers
Co-authored-by: Saurabh Mehta <saurabh1.mehta@airtel.com>
Co-authored-by: Sojan Jose <sojan@pepalo.com>
- feature to store contact IP for accounts
- IP lookup through geocoder gem
- ability to do IP lookup through external APIs
- add commit hook to prevent push to develop and master
- migrations to fix default values for jsonb columns
- Introduce models & migrations for portals, categories, folders and articles
- CRUD API for portals
- CRUD API for categories
Addresses: #714
Co-authored-by: Sojan <sojan@pepalo.com>
* Chore: Feature lock email settings in UI
The email settings under account settings needed to be
feature locked in a way different from teh current way for it
to be enabled for accounts in a self hosted scenario.
Some refactorings were also done along with this change.
1. There was a feature flag defined in code in account model called
domain_emails_enabled was used to check if the inbound emails was
enabled for the account. But there was already a feature flag called
"inbound_emails" defined in features.yml. So changed to use this to
check if inbound emails are enabled for an account.
2. Renamed and re-purposed existing `domain_emails_enabled` to
`custom_email_domain_enabled` to use for feature toggling the UI
for email settings.
3. To enable & disable multiple features using the featurable concern
we were passing an array of values. Changed this to accept a comma
separated set of values.
* Chore: Feature lock email settings in UI
Fixed the specs for accounts controller & removed
unneccessary code from Account seetings component in UI
* Chore: Convert newlines to <br>s
Removed the layout used while sending replies in
conversation continuity.
Converted the newlines in the messages to <br/> tags
for the correct HTML rendering.
* Chore: Bug fix in reply email domain
Renamed the function custom_email_domain_enabled to
inbound_email_enabled.
Fixed bug on setting reply emails's domain.
* Added custom Message-ID and In-Reply-To headers for conversation reply emails
* Added new global config for the default domain (This is used in the above headers)
* Added migration to run the config loader to load the new global config value
* The subject of the conversation reply mailer was made static (This is required for threaded emails)
* Added required tests
* Feature: Introduce Super Admins
- added new devise model for super user
- added administrate gem
- sample dashboards for users and accounts
Co-authored-by: Pranav Raj Sreepuram <pranavrajs@gmail.com>
* Renamed concern from Feature to Featurable
* Feature: Installation config (#839)
* Added new model installtion config with corresponding migrations and specs
* Created an installation config yml (key value store model)
* Created a config loader module to load the installaltion configs
* Added this to the config loader seeder
* Changed the account before create hook for default feature enabling to use the feature values from installtion config
* Renamed the feature concern to Featurable to follow the naming pattern for concerns
* Added comments and specs for modules and places that deemed necessary
* Refactored config loader to reduce cognitive complexity (#839)
* Feature: Feature flags on account (#814)
* Added the new column on account model for managing feature flags
* Added the inbound email flag
* Locked the settings of this eature in account settings based on this
* Encapsulated the feature flaging as a concern. With this, we can re-use the same concern if we introduce this in other models like user or inbox or so.
* Added the features in the account api
* Changed Rails/FilePath style - rubocop issue
* Revert "Changed Rails/FilePath style - rubocop issue"
This reverts commit 3a42d3b9c9b3a2fde8bc7256fd704b6fcaf54040.
* Disabling rubocop on codeclimate as we already have this in CICD
