* feat: Add a service layer to get AppsmithType from client-type (#16508)
This commit takes care of the following things
- It creates a service layer to get the target AppsmithType from the client-side data type and the evaluated value
- This service layer is currently not consumed by any plugins
- A full JUnit test suit for MySQL-specific types
* feat: Remove FloatType and add comments for better understanding (#16508)
* feat: Add FallbackType and covert the DataTypeService to a util class (#16508)
This commit takes care of these
- Introduce FallbackType as a separate type
- Convert the DataTypeService to a util class
- Add java doc around the methods in DataTypeService class
* feat: Rename DataTypeService to DataTypeServiceUtils (#16508)
* Refactor tests
* Use Mock.Spy to mock the method of the testing class
* Add the mock for new workspaceId in the test class
Co-authored-by: Trisha Anand <trisha@appsmith.com>
## Description
This adds the missing analytics event for workspace creation
## Type of change
- New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- Locally
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [x] New and existing unit tests pass locally with my changes
* POC: Datatype handling autogenerated naming params client
* added array and file datatype
* handles all primitive types
* paramproperties convetred to map instead of array
* parametermap inversion
* handled no bindings bug
* feat: Consume action execution payload changes w.r.t. data type mapping (#15555)
This commit does the following things
1. It consumes data type metadata from payload
2. It consumes the mapping between the pseudo binding name and original binding name
3. It doesn't apply any logic w.r.t. data type identification after consumption
* added comments and cleaned code with proper datatypes
* removed URLencoding for binding params names
* feat: Remove URL decoding on param keys from server-side codebase (#15555)
* Remove unused import (#15555)
Co-authored-by: ChandanBalajiBP <chandan@appsmith.com>
Execute action triggered events were not getting logged because of a lack of subscription. Fixed in place.
## Type of change
- Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- Locally connected to segment
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [x] New and existing unit tests pass locally with my changes
* -return custom slug in response to the get list of pages API
* -return custom slug for default page in home page API
Co-authored-by: Aishwarya UR <aishwarya@appsmith.com>
* feat: added more data to existing analytics events
* Added extra audit data points for page and action events
* Corrected minor comment issue
* Review changes
* Removed audit references in variable names
* Review changes related to sending analytics events and DB optimization
The Installation setup complete event is not getting sent sometimes, and it's behavior looks very much like there's some race condition somewhere. I'm proposing this change towards two goals.
One, currently, we send the event after the user-entered data is saved to the DB. But, there's no actual dependency, no point to waiting on that for sending the event. The actual user itself, is already created and signed up. So, one change is that we don't wait for the DB update to be applied. I'm also changing .onSuccess to .map, hoping that might make a difference.
Two, make a debug log entry to see if it is our callback function that's not getting invoked, or if Segment's API isn't doing it's job, when the event is not sent.
This PR also fixes formatting of Segment error messages.