Detail View for inquirys

[DanielZambSB]

Is your feature request related to a problem? Please describe. The current system lacks a detailed view for individual inquiries, preventing users from accessing comprehensive information and performing necessary actions on them. Users cannot create, view, edit, or delete inquiry details within the platform, which leads to an over-reliance on external processes and reduces overall efficiency.

Describe the solution you'd like The implementation of an Inquiry Detail View feature is needed to allow users to:

• Create: Add new inquiries with detailed information, including text descriptions, relevant images, and categorization tags.
• Read: View all details of an inquiry in a single, centralized interface that aggregates information from the initial request to the latest updates.
• Update: Make changes to inquiry details as the situation evolves or as new information becomes available. This should include adding follow-up notes, changing status, or updating contact information.
• Delete: Remove inquiries that are no longer relevant or have been resolved, with proper archiving of their history for future reference.

Describe alternatives you've considered While no alternatives have been considered due to the specific needs of our system, I am open to exploring third-party tools or plugins that could integrate seamlessly with our existing platform and provide these features if they can offer a quicker deployment and cost-effective solution.

Additional context A detailed view of inquiries is vital for our support team to manage and resolve maintenance issues effectively. This feature should be accessible from the listing module and designed with usability in mind, ensuring that all user roles can perform the necessary actions without extensive training. Additionally, it would be beneficial to include an audit trail feature within the detail view to track all changes made over the lifecycle of an inquiry.

[DanielZambSB]

• [x] put already selected dates into the dateRange
• [x] put into the detail the fields bogota, fecha gestion
• [x] email btn feature
• [x] whatsapp btn feature
• [x] notification & meet btn feature

[DanielZambSB]

citty getter/setter with select done

[DanielZambSB]

Date Processed Logic:

1. updating the processed date of the inquiry
   1. need to update the date processed field whenever the user changes category to "reviewed"

[DanielZambSB]

DATE PROCESSED AND DATE APROVED IMPLEMENTED, CHANGES TO DB (+ A COLUMN 'DATEAPPROVAL')

[DanielZambSB]

FIXED BUG TO VIEW REALTIME UPDATE

[DanielZambSB]

CITY SETTER NEEDS HABILITY TO UPDATE THE CITIES ARRAY IF THE CITY IS NOT FOUND INSIDE THE ARR, THEN THAT PART WOULD BE COMPLETE

[DanielZambSB]

Code Documentation

Related Files:

• JS.html
• code.gs

Related JS Functions

• parseInquiryDetails()
• reloadCities()
• addCityBtn()
• removeCityBtn()
• updateCityBtn()
• notificationDateButton()
• notificationWppInterventorBtn()
• Getters and Setters
• goToEmailListBtn()
• editDetail()
• saveDetail()
• editInquiryDetailBtn() and goToOTModuleBtn()

Related GS Functions

• compareStringDate()
• createInquiryDB()
• readInquiryDB()
• updateInquiryDB()
• deleteInquiryDB()

Documentation for parseInquiryDetails Function

The parseInquiryDetails function is crucial for retrieving and parsing specific inquiry details from a cached array based on a given identifier (ID). This function operates through the following key steps:

1. Receives an id and a cachedArray containing potential inquiry data as inputs.
2. Logs the length of the cachedArray and the provided id to track the process.
3. Initializes an empty array to store individual parsed inquiry items.
4. Iterates through the elements of the specified inquiry in the cachedArray up to a predefined limit (16 items).
5. Parses each item within this limit from JSON format and adds it to the inquiry details array.
6. Maps the parsed data to specific attributes of an inquiry detail object, such as IDs, dates, order numbers, city, and other relevant details.
7. Handles any errors during the parsing process by displaying an alert message indicating the failure, which includes the error message.

This function is essential for accessing and structuring detailed inquiry data, which can then be utilized for further processing or display within the application. It is designed to ensure that only relevant parts of the data are parsed and any issues during the process are promptly reported to enhance user experience and debugging efficiency.

Documentation for reloadCities Function

The reloadCities function is designed to refresh and repopulate the city selection dropdown in a web application, pulling data directly from an external source via a Google Apps Script. Here's a step-by-step breakdown of its functionality:

1. Clear Existing Data: The function begins by clearing any existing options in the citySelect dropdown and resets the ciudades array and ciudadesAData object which are used to store city names and their corresponding data.
2. Error Handling: Implements a failure handler using SweetAlert to notify users if there's an error in loading city data, displaying a detailed error message.
3. Data Loading and Processing:
   • Calls a Google Apps Script function readCities to fetch city data.
   • Upon successful data retrieval, the function iterates through each city data item, updating the ciudades array and ciudadesAData object with the city's text and ID.
   • Logs the updated city information for debugging purposes.
4. Dropdown Refresh: Utilizes the jQuery select2 plugin to refresh the dropdown with the new city data, applying specific settings like theme and dropdown behavior to enhance the user interface.

This function is crucial for maintaining an up-to-date and user-friendly city selection dropdown, ensuring that users have access to the latest data and can make their selections accordingly.

Documentation for click Event Handler on #addCityBtn

The jQuery event handler attached to #addCityBtn facilitates the process of adding a new city to a dropdown menu through a series of interactive dialogues and backend integrations. Here’s a detailed breakdown of its workflow:

1. User Input Prompt: When the button is clicked, a SweetAlert dialogue prompts the user to input the name of a new city. It includes validation to ensure the input is not empty.
2. Confirmation Handling:
   • If the user confirms the input, a loading dialogue appears indicating that the process of adding the new city is underway.
   • A Google Apps Script function createCity is called to handle the addition of the new city to a backend system. This function expects the city name to be passed in uppercase format.
3. Success and Error Handling:
   • On successful addition, a SweetAlert dialogue notifies the user that the city has been successfully created, displaying a message along with the city ID returned from the backend.
   • The new city is added to both the ciudades array and ciudadesAData object for local tracking, and the dropdown menu (#citySelect) is updated accordingly.
   • On failure, an error message is displayed detailing what went wrong during the addition process.
4. Cancellation Handling: If the user denies the action, a message is displayed noting that the city was not created.

This event handler enhances user interaction by providing immediate feedback and dynamically updating the user interface based on backend operations, making the city management system more responsive and user-friendly.

Documentation for click Event Handler on #removeCityBtn

The jQuery event handler attached to #removeCityBtn is designed to facilitate the deletion of a city from a dropdown menu with a confirmation mechanism to ensure intentional deletion. The function operates as follows:

1. Retrieving City Information: Upon clicking the 'Remove City' button, the currently selected city's name and corresponding ID are retrieved from the dropdown menu and a local data object, respectively.

2. User Confirmation Prompt: A SweetAlert dialog prompts the user to confirm the deletion by typing the city's name. This serves as a validation step to prevent accidental deletions.

3. Confirmation Handling:

   • If the user confirms and inputs the correct city name, a loading dialogue appears, signaling that the deletion process is underway.
   • A Google Apps Script function deleteCity is invoked to handle the removal of the city from the backend system using the city's ID.

4. Success and Error Handling:

   • On successful deletion, the user is notified with a success message indicating that the city has been removed, and the city list is refreshed by calling reloadCities to reflect the change.
   • If there's an error during the deletion, an error message displays what went wrong.

5. Cancellation Handling: If the user denies the action or inputs an incorrect city name, a message is displayed noting that the city was not deleted.

This event handler enhances the user interface by providing robust mechanisms for confirming city deletions and immediate feedback, making the city management system more secure and interactive.

Documentation for click Event Handler on #updateCityBtn

The jQuery event handler attached to #updateCityBtn manages the process of updating the name of a selected city in a dropdown menu. This is accomplished through a user interaction flow that confirms the change and then communicates with a backend service. Here’s a detailed breakdown of its functionality:

1. Retrieve Current City Information: Initially, the handler retrieves the current city's name and ID from the citySelect dropdown menu and a local data map (ciudadesAData).

2. User Input Prompt: A SweetAlert dialog prompts the user to input a new name for the city. It includes a validation step to ensure the new name is different from the current one.

3. Confirmation Handling:

   • If the user confirms the change, a loading dialogue appears, indicating that the update process is underway.
   • A Google Apps Script function updateCity is called to update the city name in the backend system using the city's ID and the new name (converted to uppercase).

4. Success and Error Handling:

   • On successful update, a SweetAlert dialogue informs the user of the successful update, displaying the new city name.
   • The city list is refreshed by calling reloadCities to reflect the updated name.
   • If there's an error during the update process, an error message details what went wrong.
   • Additionally, the form containing the city dropdown (#cityForm) is briefly blurred for visual effect to signify the update process, and then focused again once the city dropdown is updated.

5. Post-Update Adjustments: After a delay, the city dropdown is updated to show the newly updated city as selected, and the form's visual blur is removed.

This event handler enhances the user interface by providing a clear and interactive process for updating city names, ensuring data integrity and improving user experience through dynamic feedback and visual effects.

Documentation for click Event Handler on #notificationDateButton

The jQuery event handler attached to #notificationDateButton manages the setting of reminders through a user interface that involves date selection. Here's a detailed breakdown of its workflow:

1. User Input Prompt: When the button is clicked, a SweetAlert dialog prompts the user to select a time for the reminder. This includes a custom input field for date and time selection using flatpickr, a lightweight and powerful datetime picker.

2. Date Picker Configuration:

   • Depending on the presence of valid start (radicationDate) and end (quotationDate) dates, the date picker is configured with constraints such as minimum and maximum dates and times.
   • If the end date is not in a standard format, a Google Apps Script (translateDate) is invoked to convert it into a recognizable format before initializing the date picker.

3. Handling Date Selection:

   • The date selection from the picker is stored in a variable date upon the closure of the picker dialog.
   • If no valid date is selected when the user attempts to save the reminder, an error message is displayed prompting them to select a valid time.

4. Confirmation Handling:

   • If the user confirms the reminder and a valid date is selected, the reminder details are processed. A loading message is shown as the system processes the reminder setup.
   • A Google Apps Script function createEventForInquiry is called to save the reminder in the system, associated with specific inquiry details.

5. Success and Error Handling:

   • On successful reminder setup, a confirmation message displays the scheduled date and time.
   • If there's an error during the process (either in date selection or reminder setup), an error message details what went wrong.

6. Cancellation Handling: If the user denies the action, a cancellation message confirms that no reminder was set.

This event handler enhances the user interface by providing a detailed and interactive process for setting reminders, ensuring that users can easily schedule and manage reminders linked to specific inquiries.

Documentation for click Event Handler on #notificationWppInterventorBtn

The jQuery event handler attached to #notificationWppInterventorBtn orchestrates the process of sending communication messages (email and WhatsApp) to an intervener based on user-entered and pre-populated data. Here’s how it functions:

1. User Interaction for Data Verification: Upon clicking the button, a SweetAlert dialogue prompts the user to verify or complete the intervener’s contact details, such as phone number, email, and other relevant inquiry details.

2. Dynamic Form Configuration:

   • The form presented in the dialogue includes toggle switches for selecting the communication channels (email and WhatsApp).
   • The user can input or modify data like the intervener’s phone number, email, name, order number, and other details.

3. Communication Preferences Handling:

   • Based on the user’s selection of communication channels, the function prepares for sending messages via the selected methods after form submission.

4. Data Validation and Message Sending:

   • Validates the phone number and email to ensure they are in correct formats.
   • If validation passes, Google Apps Script functions are invoked to send the messages through the specified channels (requestSendTemplate for WhatsApp and sendEmailComunication for email).

5. Success and Error Handling:

   • Displays a loading indicator while messages are being sent.
   • On successful message delivery, confirms the completion with a success alert.
   • If there’s an error (e.g., in the data format or communication process), it displays a detailed error message.
   • Additionally, it attempts to save contact details to a backend system, providing feedback on the outcome.

6. Cancellation Handling: If the user cancels the operation, an alert notifies them that the communication was not sent.

This event handler enhances the application’s functionality by allowing direct and personalized communication with interveners, supporting both immediate and verified message dispatching. It ensures data integrity and user confirmation before sending critical communication.

Overview of Getters and Setters Functions for Inquiry Details Interface

The provided JavaScript functions are essential for managing UI interactions in a web application concerning the enabling/disabling of input fields and buttons, as well as setting and retrieving values from these fields related to inquiry details. Here's a brief description of each function's role:

Disabling and Enabling Functions:

• disableValues(): Disables all text inputs and textareas within the #emailDetailInquiryModule and the #citySelect dropdown, preventing the user from modifying the content.
• enableValues(): Re-enables the inputs within the #emailDetailInquiryModule and the #citySelect dropdown, allowing the user to edit the content.
• disableDetailButtons(): Disables specific buttons related to notifications and city management, but enables buttons for adding, removing, and updating cities.
• enableDetailButtons(): Enables notification-related buttons and disables city management buttons, reversing the effect of disableDetailButtons().

Setting and Getting Inquiry Detail Values:

• setDetailValues(inquiry): Populates various UI components with data from the inquiry object. This includes text inputs, text areas, badges for categories, and selection of the city from a dropdown. It sets the inquiry's detailed information such as title, description, emails, dates, and other relevant fields.
• getDetailValues(): Retrieves the values from UI components and updates the inquiryDetail object. This function handles inputs like descriptions, dates, emails, and others, ensuring that they are captured and stored correctly, possibly for further processing or validation.

These functions are critical for a dynamic web application where user interaction with data is frequent, ensuring that data integrity is maintained while providing a responsive user experience.

Documentation for click Event Handler on #goToEmailListBtn

The jQuery event handler attached to #goToEmailListBtn manages the transition from viewing detailed inquiry information back to the corresponding list of inquiries, with visual cues to locate the previously viewed inquiry. Here’s how it operates:

1. Context and Screen Transition:

   • Checks the current inbox context (inboxContext.currentInbox) to determine which inbox or screen to display, helping manage transitions across potentially multiple views or inboxes.
   • Calls switchScreens, a function to change the current view based on the inbox type (main or others).

2. Highlighting the Previously Viewed Inquiry:

   • If in the "main" inbox, scrolls to and visually highlights the previously viewed inquiry by modifying the CSS to apply a temporary border.
   • For other inboxes, locates the inquiry based on its relative ID within the inbox, scrolls to it, and applies a similar visual highlighting.

3. Visual Feedback:

   • The highlighted border is removed after a short delay (3000 milliseconds), providing a transient but clear visual indicator to help the user locate the inquiry.

4. Update and Cleanup:

   • Sets detailInquiryOptions.editInquiry to false, indicating that any edit operations are concluded.
   • Calls saveDetail(false) to handle any potential data changes, ensuring no inadvertent edits are committed when leaving the detailed view.

5. Ensuring Smooth User Experience:

   • Enhances user navigation by clearly marking the transition paths and providing feedback on the location of specific inquiries, thus improving the overall usability and efficiency of the user interface.

Documentation for editDetail Function

The editDetail function in the web application is responsible for enabling the editing of details in the inquiry view. This function adjusts the user interface to facilitate user interaction and data entry. Here's how it functions:

1. UI Button Update: Transforms the "Edit" button into a "Save" button, changing its class to reflect the action that will be taken upon the next click. This provides a visual cue to the user that the inquiry is in edit mode and changes can be saved.

2. Enabling and Disabling Inputs:

   • Calls enableValues() to enable text inputs and textareas within the detail view, allowing the user to modify existing data.
   • Calls disableDetailButtons() to disable other control buttons during the editing process to prevent conflicting actions.

3. Date Range Picker Initialization:

   • Hides the static date display and shows an interactive date range picker.
   • Uses flatpickr to handle date inputs, providing a range selector for picking start and end dates from a calendar.
   • Configures the date picker to parse and handle dates appropriately based on existing data formats.
   • Saves the selected dates into detailInquiryOptions.dateArray upon picker closure, ensuring that the chosen dates are stored for further actions like saving or processing.

4. Error Handling and Data Translation:

   • In cases where dates need conversion (e.g., due to locale or format discrepancies), it attempts to translate the dates with backend assistance (google.script.run).
   • Handles errors during date translation with an error message, providing feedback to the user about issues encountered during the operation.

5. Dynamic Content Management:

   • Temporarily blurs the date range picker when it's uncertain or needs user attention, then removes the blur effect once dates are properly initialized or corrected.
   • This function ensures a robust and user-friendly interface for editing critical details of inquiries, enhancing data integrity and user experience by allowing precise control over the date information and other editable fields.

Documentation for saveDetail Function

The saveDetail function manages the process of saving or updating inquiry details within the web application. It toggles the user interface from edit mode back to view mode and commits changes to the backend system if specified. Here's a detailed breakdown of its operation:

1. UI Button Update: Transforms the "Save" button back to an "Edit" button, changing its class to reflect that the inquiry details are no longer in edit mode but can be edited again. This provides a clear visual indication to the user that the inquiry details are now set and the edit session has ended.

2. Disabling and Enabling Inputs:

   • Calls disableValues() to disable text inputs and textareas within the detail view, preventing further modifications.
   • Calls enableDetailButtons() to re-enable other control buttons after the editing process, allowing normal operations.

3. Handling Date Inputs:

   • Retrieves and formats selected dates from detailInquiryOptions.dateArray using flatpickr, ensuring they are formatted correctly as "d/m/Y" for display and storage.
   • Clears the temporary storage (dateArray) to reset the state for future edits.
   • Updates the UI with the formatted dates and toggles visibility of date inputs and static date displays accordingly.

4. Retrieving and Displaying Updated Values:

   • Calls getDetailValues() to capture all edited values from the input fields, preparing them for potential backend updates.
   • Provides console logs to help trace the internal state and values captured during the edit process.

5. Backend Update Conditional:

   • Checks if the updateFlag is true, indicating whether the changes should be saved to the backend.
   • If true, displays a loading message and makes a backend call to update the inquiry details in the database.
   • Handles success and failure of the update operation with appropriate user notifications. On success, updates the local inquiryList with the new details from the response, ensuring the frontend matches the backend state.

6. Success and Error Handling:

   • On successful update, displays a success message with details from the backend response.
   • On failure, displays an error message detailing what went wrong during the update process.

This function is crucial for ensuring data integrity and providing a seamless user experience during the editing and updating of inquiry details. It ensures that all changes are either committed or discarded based on user actions and provides clear feedback on the outcome of those actions.

Documentation for Event Handlers on #editInquiryDetailBtn and #goToOTModuleBtn

#editInquiryDetailBtn Click Event Handler

The jQuery event handler attached to #editInquiryDetailBtn toggles the editing state of an inquiry detail view. This function is designed to switch between editing and viewing modes dynamically based on user interaction. Here's how it operates:

1. Toggle Edit State: Changes the detailInquiryOptions.editInquiry flag to its opposite state (true to false or vice versa), which indicates whether the detail view is in edit mode.
2. Conditional Function Execution:
   • If entering edit mode (detailInquiryOptions.editInquiry is true), calls editDetail() to enable form fields and adjust the interface for user editing.
   • If exiting edit mode (detailInquiryOptions.editInquiry is false), calls saveDetail(true) to save the changes made during the edit session to the backend database and revert the interface back to view mode.

#goToOTModuleBtn Click Event Handler

The event handler on #goToOTModuleBtn manages the transition from the current screen to the OT (Order Tracking) module, with a prerequisite check for communication actions. It ensures that necessary steps are completed before allowing the user to proceed. Here’s the function breakdown:

1. Communication Check: Before switching to the OT module, verifies if at least one communication (WhatsApp or email) has been sent to the intervener (detailInquiryOptions.commsSent).
2. Conditional Navigation:
   • If the communication requirement is met, executes several functions to transition to the OT module:
     • Calls fillingInquiryDataSoFar() to populate the OT module with the latest inquiry data.
     • Uses switchScreens("OT") to change the current view to the OT module.
     • Calls equalizeCardHeights() to adjust the heights of UI cards for visual consistency.
     • Resets the window scroll to the top and calls saveDetail(false) to ensure no uncommitted edits are carried over.
   • If the communication has not been sent, displays a warning message prompting the user to complete this step before proceeding.

These handlers enhance the application's interactivity and data integrity, ensuring that users follow necessary procedures and maintain accurate state transitions between different modules and views.

GS Functions

Documentation for compareStringDate Function

The compareStringDate function is designed to compare two dates, where the first date (d1) is provided as a string in the "DD/MM/YYYY" format, and the second date (d2) is a JavaScript Date object. This function is useful for scenarios where date comparisons are required to determine the chronological order of events or validate time-based conditions. Here's a breakdown of its functionality:

• Parsing and Preparation:

  • The string date d1 is split into its constituent parts (day, month, year), and these are used to construct a new Date object, date1.
  • The Date object date2 is adjusted to remove the time component, focusing the comparison strictly on the date.

• Comparison Logic:

  • The function compares the time values (milliseconds since the epoch) of date1 and date2.
  • If date1 is later than date2, it logs a message indicating this and returns 1.
  • If date1 is earlier than date2, it logs a message to that effect and returns -1.
  • If the dates are equal, it logs that they are the same and returns 0.

This function is essential for applications where dates need to be compared for sorting, filtering, or conditional workflows based on temporal data.

Documentation for createInquiryDB Function

The createInquiryDB function is integral to managing inquiry records in a Google Sheets-based database system. This function either creates a new inquiry record or updates an existing one based on the presence of an ID within the inquiry object. Here's a detailed breakdown of its operation:

1. Initialization:

   • Opens a specific Google Sheet named "BD_seguimiento" by referencing its spreadsheet ID, which serves as the storage for inquiry data.

2. Check for Existing Record:

   • Checks if the incoming inquiry object contains an 'id' field. If it does, this implies that the record exists and needs to be updated rather than created. It then delegates to updateTemplateObjectToDB for handling the update.

3. ID and Date Handling:

   • If creating a new record, it determines the next available ID by retrieving the last row's ID and incrementing it. This ensures each inquiry has a unique identifier.
   • Records the current date and time as the request date, formatting it as a JSON string for consistency and compatibility with spreadsheet operations.

4. Data Preparation and Row Construction:

   • Maps over a predefined list of keys (keysOrder), extracting values from the inquiry object. If a key is present in the inquiry, its value is stringified; if not, an empty string is used. This prepares a structured array of inquiry data for insertion.
   • Constructs a row array starting with the new ID, followed by the request date and the array of prepared values.

5. Appending to Spreadsheet:

   • Appends the constructed row to the "BD_seguimiento" sheet, effectively storing the new inquiry data in the database.
   • Updates the inquiry object with the new ID, ensuring that the in-memory representation is accurate and up-to-date.

6. Return Value:

   • Returns a success status and the new inquiry ID, providing feedback about the operation's success and the identifier for the newly created or updated record.

This function is essential for applications that require a robust and straightforward method to manage inquiry data using Google Sheets, offering a scalable and easy-to-integrate solution for environments where traditional databases are not feasible or preferred.

Documentation for readInquiryDB Function

The readInquiryDB function is a key component of the inquiry management system, designed to retrieve specific inquiry records from a Google Sheets-based database by their unique ID. Here's an in-depth look at how this function operates:

1. Initialization:

   • Opens the Google Sheet titled "BD_seguimiento", which serves as the database storing all inquiries. This sheet is accessed using its unique ID, ensuring the function targets the correct data repository.

2. Search for Inquiry by ID:

   • Defines the column range (A:A) where inquiry IDs are stored and uses Google Sheets' createTextFinder method to search for the specific inquiry ID (pId). This method is set to match the entire cell content to ensure exact matches only.
   • If no matching rows are found, the function logs an error message indicating that the ID was not found in the sheet and returns an error status code along with a message. This step ensures the function handles the absence of data gracefully.

3. Data Retrieval:

   • If a matching row is found, the function retrieves the row index and extracts the entire row of data from the sheet.
   • Since the first two cells contain meta-information (ID and possibly a timestamp), the function slices the array from the third element onwards to focus on the actual inquiry data.

4. Data Parsing and Structuring:

   • Iterates through each cell of the sliced array using a predefined order of keys (keysOrder) to map each cell to a corresponding attribute of an inquiry object.
   • Attempts to parse each cell value as JSON to accommodate complex data structures stored as strings. If parsing fails (e.g., for plain strings or numbers), it defaults to storing the raw value.
   • This structured approach ensures that the retrieved inquiry data is formatted correctly and is consistent with the application's data handling expectations.

5. Logging and Return:

   • Logs the retrieved cell data and the final structured inquiry data for debugging purposes, aiding in troubleshooting and verification of data integrity.
   • Returns a success status code along with the structured inquiry data, making it available for further processing or display in the application.

This function is crucial for applications that require reliable retrieval of specific records from a dataset based on unique identifiers. It supports functionalities such as viewing detailed inquiry records, editing existing records, or auditing changes.

Documentation for updateInquiryDB Function

The updateInquiryDB function plays a critical role in managing inquiry data by updating existing records within a Google Sheets-based database. This function ensures that any modifications to an inquiry are reflected accurately in the database, maintaining data integrity and relevancy. Here’s a detailed breakdown of its operation:

1. Initialization:

   • Accesses the "BD_seguimiento" sheet within a specific Google Spreadsheet identified by its unique ID. This sheet is used to store and manage all inquiry records.

2. Data Preparation:

   • Maps over a predefined list of keys (keysOrder), which represents the expected structure of inquiry data. For each key, it retrieves the corresponding value from the newInquiry object. If the key exists, the value is stringified (to ensure consistency in how data is stored); if it does not exist, an empty string is used as a placeholder.
   • This structured approach ensures that all necessary attributes of an inquiry are accounted for, even if some data points were not updated in the new submission.

3. Search for Existing Record:

   • Utilizes the createTextFinder method to search the ID column for the provided pId, ensuring the inquiry to be updated is correctly identified.
   • If the ID is found, it retrieves the row index for the matching record. If not found, it logs an error stating that the ID was not found, which helps in debugging and error handling.

4. Updating the Record:

   • Prepares an array of data (updatedData) that includes the inquiry ID, the current date (formatted as a JSON string), and the array of new data values.
   • Uses the setValues method to update the row in the sheet corresponding to the found ID with the new data array. This method replaces the entire row's data, ensuring that all changes are applied.

5. Logging and Feedback:

   • Logs both the original inquiry data and the updated data array for auditing and debugging purposes.
   • Returns a success status along with the updated data array, providing immediate feedback about the operation's success and the updated state of the inquiry.

This function is essential for applications requiring consistent and up-to-date record-keeping, especially in dynamic environments where inquiry details may frequently change. It supports robust data management practices by ensuring that updates are accurately and efficiently processed.

Documentation for deleteInquiryDB Function

The deleteInquiryDB function is designed to safely remove inquiry records from a Google Sheets-based database while maintaining a history of deletions for audit and recovery purposes. Here’s a detailed breakdown of its operation:

1. Initialization and Access:

   • Opens two specific Google Sheets within the same spreadsheet: BD_seguimiento for current inquiry records and BD_deleted_records for tracking deletions.
   • These sheets are accessed using their unique IDs, ensuring that the function targets the correct data repository for operations.

2. Search for the Inquiry Record:

   • Utilizes Google Sheets' createTextFinder to search for the inquiry ID (pId) within the BD_seguimiento sheet. This method is configured to match the entire cell content accurately.
   • If no matching inquiry is found, it logs this information for debugging purposes, indicating that the ID was not present in the database.

3. Handling the Deletion ID:

   • Retrieves the last row index used in the BD_deleted_records sheet to ensure that each deleted record can be uniquely identified and later reviewed if necessary.
   • Increments this ID if necessary to maintain a sequential, unique identifier for new deletions.

4. Deletion and History Recording:

   • If the inquiry is found, the function retrieves the entire row of data, logs it for record-keeping, and then slices off the first two entries (typically metadata like ID and timestamps) to focus on the inquiry-specific data.
   • Deletes the row from the BD_seguimiento sheet, effectively removing the inquiry from active records.
   • Appends a new row to the BD_deleted_records sheet with the deletion ID, the deletion date, and the data of the deleted inquiry. This ensures that there is a historical record of what was deleted, which can be crucial for audits or data recovery.

5. Final Operations and Return:

   • Logs the details of the deleted record for transparency and confirmation of the operation.
   • Returns a success status code to indicate that the deletion was processed successfully.

This function is essential for maintaining the integrity and cleanliness of the database while ensuring that deletions are traceable and reversible if necessary. It supports compliance with data management policies that require record keeping even for deleted entries.

#

[DanielZambSB]