Class ScheduledReportTableCustomizer

java.lang.Object
com.kingsrook.qqq.backend.core.model.savedreports.ScheduledReportTableCustomizer
All Implemented Interfaces:
TableCustomizerInterface
public class ScheduledReportTableCustomizer extends Object implements TableCustomizerInterface

  • Constructor Details

    • ScheduledReportTableCustomizer

      public ScheduledReportTableCustomizer()

  • Method Details

    • preInsert

      public List<QRecord> preInsert(InsertInput insertInput, List<QRecord> records, boolean isPreview) throws QException
      Description copied from interface: TableCustomizerInterface
      custom actions before an insert takes place. It's important for implementations to be aware of the isPreview field, which is set to true when the code is running to give users advice, e.g., on a review screen - vs. being false when the action is ACTUALLY happening. So, if you're doing things like storing data, you don't want to do that if isPreview is true!! General implementation would be, to iterate over the records (the inputs to the insert action), and look at their values: - possibly adding Errors (`addError`) or Warnings (`addWarning`) to the records - possibly manipulating values (`setValue`) - possibly throwing an exception - if you really don't want the insert operation to continue. - doing "whatever else" you may want to do. - returning the list of records (can be the input list) that you want to go on to the backend implementation class.
      Specified by:
      preInsert in interface TableCustomizerInterface
      Throws:
      QException

    • preUpdate

      public List<QRecord> preUpdate(UpdateInput updateInput, List<QRecord> records, boolean isPreview, Optional<List<QRecord>> oldRecordList) throws QException
      Description copied from interface: TableCustomizerInterface
      custom actions before an update takes place. It's important for implementations to be aware of the isPreview field, which is set to true when the code is running to give users advice, e.g., on a review screen - vs. being false when the action is ACTUALLY happening. So, if you're doing things like storing data, you don't want to do that if isPreview is true!! General implementation would be, to iterate over the records (the inputs to the update action), and look at their values: - possibly adding Errors (`addError`) or Warnings (`addWarning`) to the records - possibly manipulating values (`setValue`) - possibly throwing an exception - if you really don't want the update operation to continue. - doing "whatever else" you may want to do. - returning the list of records (can be the input list) that you want to go on to the backend implementation class. Note, "old records" (e.g., with values freshly fetched from the backend) will be available (if the backend supports it)
      Specified by:
      preUpdate in interface TableCustomizerInterface
      Throws:
      QException

    • postInsert

      public List<QRecord> postInsert(InsertInput insertInput, List<QRecord> records) throws QException
      Description copied from interface: TableCustomizerInterface
      custom actions after an insert takes place. General implementation would be, to iterate over the records (the outputs of the insert action), and look at their values: - possibly adding Errors (`addError`) or Warnings (`addWarning`) to the records - possibly throwing an exception - though doing so won't stop the update, and instead will just set a warning on all of the updated records... - doing "whatever else" you may want to do. - returning the list of records (can be the input list) that you want to go back to the caller.
      Specified by:
      postInsert in interface TableCustomizerInterface
      Throws:
      QException

    • postUpdate

      public List<QRecord> postUpdate(UpdateInput updateInput, List<QRecord> records, Optional<List<QRecord>> oldRecordList) throws QException
      Description copied from interface: TableCustomizerInterface
      custom actions after an update takes place. General implementation would be, to iterate over the records (the outputs of the update action), and look at their values: - possibly adding Errors (`addError`) or Warnings (`addWarning`) to the records? - possibly throwing an exception - though doing so won't stop the update, and instead will just set a warning on all of the updated records... - doing "whatever else" you may want to do. - returning the list of records (can be the input list) that you want to go back to the caller. Note, "old records" (e.g., with values freshly fetched from the backend) will be available (if the backend supports it).
      Specified by:
      postUpdate in interface TableCustomizerInterface
      Throws:
      QException

    • postDelete

      public List<QRecord> postDelete(DeleteInput deleteInput, List<QRecord> records) throws QException
      Description copied from interface: TableCustomizerInterface
      Custom actions after a delete takes place. General implementation would be, to iterate over the records (ones which didn't have a delete error), and look at their values: - possibly adding Errors (`addError`) or Warnings (`addWarning`) to the records? - possibly throwing an exception - though doing so won't stop the delete, and instead will just set a warning on all of the deleted records... - doing "whatever else" you may want to do. - returning the list of records (can be the input list) that you want to go back to the caller - this is how errors and warnings are propagated .
      Specified by:
      postDelete in interface TableCustomizerInterface
      Throws:
      QException