This blog post emphasizes on the workflow of event invoicing for organizers in Open Event. The Open Event Project, popularly known as Eventyay is an event management solution which provides a robust platform to manage events, schedules multi-track sessions and supports many other features.

Organizer invoicing in layman terms is the fee paid by an organizer for hosting an event on the platform. This is calculated every month and respective emails/notifications are sent to the user. An event invoice in the form a PDF is generated monthly based on the sales generated. The organizer can pay the invoice via a credit/debit card through PayPal.

This feature was divided into a set of sub-features namely:

1. Integration of ember tables for event invoices
2. Implementing the review route & corresponding logic
3. Creating a compatible paypal component to work with invoice workflow
4. Creation of a payment completion page on successful invoice payments

Navigating to Account > Billing Info > Invoices, we are presented with a table of all the invoices which are due, paid & upcoming. You can review your due invoices and pay them. Adding to that, you can also view any past invoices which were paid or the upcoming ones which would have a draft status with the information about the current sales. 

                                                         Event Invoice Overview – Organizers

For an invoice which is due, an organizer will be able to navigate to the review route by clicking on the Review Payment Action. In this route, details pertaining to Admin billing details, User billing details, total number of tickets sold and total invoice amount will be depicted. The Organizer can have a look at the total invoice amount here.

                                              Review Route – Invoice Payment

The Invoice details and Billing Info components were built using ui segments. 

After reviewing the information, the organizer can click on pay via PayPal to initiate the transaction process via PayPal. The challenge here was the lack of proper API routing(sandbox/live) present in the system. To overcome this, the env variable in the PayPal component was given the value of the current environment enabled.

def send_monthly_event_invoice():
    from app import current_app as app
    with app.app_context():
        events = Event.query.filter_by(deleted_at=None, state='published').all()
        for event in events:
            # calculate net & gross revenues
            user = event.owner
            admin_info = get_settings()
            currency = event.payment_currency
            ticket_fee_object = db.session.query(TicketFees).filter_by(currency=currency).one()
            ticket_fee_percentage = ticket_fee_object.service_fee
            ticket_fee_maximum = ticket_fee_object.maximum_fee
            orders = Order.query.filter_by(event=event).all()
            gross_revenue = event.calc_monthly_revenue()
            ticket_fees = event.tickets_sold * (ticket_fee_percentage / 100)
            if ticket_fees > ticket_fee_maximum:
                ticket_fees = ticket_fee_maximum
            net_revenue = gross_revenue - ticket_fees
            payment_details = {
                'tickets_sold': event.tickets_sold,
                'gross_revenue': gross_revenue,
                'net_revenue': net_revenue,
                'amount_payable': ticket_fees
            }
            # save invoice as pdf
            pdf = create_save_pdf(render_template('pdf/event_invoice.html', orders=orders, user=user,
                                  admin_info=admin_info, currency=currency, event=event,
                                  ticket_fee_object=ticket_fee_object, payment_details=payment_details,
                                  net_revenue=net_revenue), UPLOAD_PATHS['pdf']['event_invoice'],
                                  dir_path='/static/uploads/pdf/event_invoices/', identifier=event.identifier)
            # save event_invoice info to DB

            event_invoice = EventInvoice(amount=net_revenue, invoice_pdf_url=pdf, event_id=event.id)
            save_to_db(event_invoice)

                                Invoice generation and calculation logic as a cron job

The event invoice PDFs along with the amount calculation was done on the server side by taking the product of the number of tickets multiplied by eventyay fees. The invoice generation, amount calculation and the task of marking invoices as due were implemented as cron jobs which are scheduled every month from the time the event was created.

def event_invoices_mark_due():
    from app import current_app as app
    with app.app_context():
        db.session.query(EventInvoice).\
                    filter(EventInvoice.status == 'upcoming',
                           EventInvoice.event.ends_at >= datetime.datetime.now(),
                           (EventInvoice.created_at + datetime.timedelta(days=30) <=
                            datetime.datetime.now())).\
                    update({'status': 'due'})

        db.session.commit()

                                            Cron job to mark invoices as due

As soon as the payment succeeds, the organizer is routed to the paid route where the information alluding to the PayPal ID, Amount can be found. The organizer can also download their invoice using the route action similar to tickets and order invoices generation on Eventyay.

                                           Organizer View – Paid Invoice Route

Resources:

• Tutorial on scheduling cron jobs
• Ember Route documentations
• Model Hooks reference

Related work and code repo:

• Front-End Repository
• API Server Repository
• Organizer View – Review Route implementation

• Invoice Generation and Calculation logic
• Event Invoice – Ember Tables

Tags:

Eventyay, FOSSASIA, Flask, Ember.js, Open Event, API

This blog post emphasizes the power of ember tables and how it was leveraged to implement the event invoice view for eventyay. Event Invoices can be defined as the fee given by the organizer for hosting the event on the platform. 

Eventyay is the outstanding Open Event management solution using standardized event formats developed at FOSSASIA. Porting from v1 to v2, event invoices are an integral part in the process. 

Initially, throughout the whole project, plain HTML tables were utilized to render data pertaining to sales, tickets info etc. This in turn made the task of rendering data a cumbersome one. To implement clean & ubiquitous tables with in-built search & pagination functionalities, the ember addon ember-table has been used in Eventyay v2.

To integrate ember tables, the HTML tables had to be replaced with the ember-table component which was created in the Open Event Project. 

To utilize this component, column names for upcoming, paid and due invoices are required. These are stored in Plain Old Javascript Objects (POJOs) in the controller logic passed to the appropriate ember-table component.

In the template logic, we check for the params i.e invoice status in this case and render the ember table through a component. Certain parameters such as the searchQuery, metaData, filterOptions etc. were to be passed in for total control of the table.

@computed()
  get columns() {
    let columns = [];
    if (this.model.params.invoice_status === 'upcoming') {
      columns = [
        {
          name      : 'Invoice ID',
          valuePath : 'identifier'
        },
        {
          name          : 'Event Name',
          valuePath     : 'event',
          cellComponent : 'ui-table/cell/events/cell-event-invoice'
        },
        {
          name      : 'Date Issued',
          valuePath : 'createdAt'
        },
        {
          name            : 'Outstanding Amount',
          valuePath       : 'amount',
          extraValuePaths : ['event'],
          cellComponent   : 'ui-table/cell/events/cell-amount'
        },
        {
          name      : 'View Invoice',
          valuePath : 'invoicePdfUrl'
        }
      ];
    } else if (this.model.params.invoice_status === 'paid') {
      columns = [
        {
          name      : 'Invoice ID',
          valuePath : 'identifier'
        },
        {
          name          : 'Event Name',
          valuePath     : 'event',
          cellComponent : 'ui-table/cell/events/cell-event-invoice'
        },
        {
          name      : 'Date Issued',
          valuePath : 'createdAt'
        },
        {
          name            : 'Amount',
          valuePath       : 'amount',
          extraValuePaths : ['event'],
          cellComponent   : 'ui-table/cell/events/cell-amount'
        },
        {
          name      : 'Date Paid',
          valuePath : 'completedAt'
        },
        {
          name      : 'View Invoice',
          valuePath : 'invoicePdfUrl'
        },
        {
          name            : 'Action',
          valuePath       : 'identifier',
          extraValuePaths : ['status'],
          cellComponent   : 'ui-table/cell/events/cell-action'
        }

      ];
    } else if (this.model.params.invoice_status === 'due') {
      columns =   [
        {
          name      : 'Invoice ID',
          valuePath : 'identifier'
        },
        {
          name          : 'Event Name',
          valuePath     : 'event',
          cellComponent : 'ui-table/cell/events/cell-event-invoice'

        },
        {
          name      : 'Date Issued',
          valuePath : 'createdAt'
        },
        {
          name            : 'Amount Due',
          valuePath       : 'amount',
          extraValuePaths : ['event'],
          cellComponent   : 'ui-table/cell/events/cell-amount'
        },
        {
          name      : 'View Invoice',
          valuePath : 'invoicePdfUrl'
        },
        {
          name            : 'Action',
          valuePath       : 'identifier',
          extraValuePaths : ['status'],
          cellComponent   : 'ui-table/cell/events/cell-action'
        }

      ];
    } else if (this.model.params.invoice_status === 'all') {
      columns = [
        {
          name      : 'Invoice ID',
          valuePath : 'identifier'
        },
        {
          name          : 'Event Name',
          valuePath     : 'event',
          cellComponent : 'ui-table/cell/events/cell-event-invoice'
        },
        {
          name            : 'Amount',
          valuePath       : 'amount',
          extraValuePaths : ['event'],
          cellComponent   : 'ui-table/cell/events/cell-amount'
        },
        {
          name      : 'Status',
          valuePath : 'status'
        },
        {
          name            : 'Action',
          valuePath       : 'identifier',
          extraValuePaths : ['status'],
          cellComponent   : 'ui-table/cell/events/cell-action'
        }

      ];
    }
    return columns;
  }
}

In the route logic, the queryObject is defined to specify the default page size, page numbers and the filter applied to query the event invoice model. A sorting filter is additionally applied to pre-sort the entries before rendering it. We return the data and the params under the model hook which is then used inside the template.

For the implementation of filters, we specify the type of filters we use by storing them in a filterOptions object. For paid and due invoices, we query the event invoice model, checking if the invoice_status is paid or due. The challenge for upcoming invoices was that we won’t be able to name every other invoice as an upcoming one. Therefore, the solution which was utilized here was to query only those events which whose createdAt(date created) attribute was less than 30 days and those which weren’t deleted using Soft Deletion.

These invoices were rendered using the tabbed navigation component complying with the existing code practices.

  async model(params) {
    this.set('params', params);
    const searchField = 'name';
    let filterOptions = [];
    if (params.invoice_status === 'paid' || params.invoice_status === 'due') {
      filterOptions = [
        {
          name : 'status',
          op   : 'eq',
          val  : params.invoice_status
        }
      ];
    } else if (params.invoice_status === 'upcoming') {
      filterOptions = [
        {
          and: [
            {
              name : 'deleted-at',
              op   : 'eq',
              val  : null
            },
            {
              name : 'created-at',
              op   : 'ge',
              val  : moment().subtract(30, 'days').toISOString()
            }
          ]
        }
      ];
    }


    filterOptions = this.applySearchFilters(filterOptions, params, searchField);

    let queryString = {
      include        : 'event',
      filter         : filterOptions,
      'page[size]'   : params.per_page || 10,
      'page[number]' : params.page || 1
    };

    queryString = this.applySortFilters(queryString, params);
    return {
      eventInvoices: (await this.store.query('event-invoice', queryString)).toArray(),
      params

    };

  }

Model Hook for ember invoice tables

Resources:

• Ember table documentation
• Create a basic ember table tutorial
• Creating an ember model

Related work and code repo:

• Front-End Repository
• API Server Repository
• Integration of Event Invoices using Ember tables

Tags:

Eventyay, FOSSASIA, Flask, Ember Tables, SQLAlchemy, Open Event, Python

So before we get started let me quickly show you what we accomplished over a period of 2 and a half months building the Pocket Science Lab desktop app using the very technology I am going to talk about.

The PSLab desktop app was originally written using pyQt. The UI of the python stack looked really outdated and maintaining it was becoming a problem due to poor developer support. So, after a lot of discussion and experimentation, we finally decided to re-implement the whole app in electronJS. There are three major benefits of writing an app with Electron:

• You can re-use your HTML, CSS knowledge to write the UI part in no time.
• You can re-use your JavaScript knowledge to write the business logic of the app.
• It works…

Why?

Before we even dive down to why use X and why use Y, let us try to answer a very basic question, The reason I had to invest a massive amount of time trying to experiment with different combinations and config parameters is because most of the blogs on the internet just wrote about “How to get started”, nobody talked about how to complete the build. And that is what I am going to cover. Anyone can figure out how to start out but  the real grind only begins when you get to the details of the app. But I hope to hit the escape velocity with my take on the subject.

The Tech Stack — Why we chose Electron for PSLab Desktop app

Now let’s talk about why we need React or Python in an Electron App.

1. React

It is perfectly fine to use everything minimal, plain old HTML, CSS and JS will do just fine for your UI, but for how long? React opens up so many possibilities and makes the code logic flow naturally through a very well designed UI language. The state management system is also brilliant and the most crucial thing that will definitely make your life easier is the life cycle methods offered by React class components. Making use of react also lets you take advantage of well known React oriented libraries like Material UI React, and Styled-Components. These things are game changers and can transform your UI to an absolute gem that your users will enjoy.

Oh, by the way, React UI is blazing fast…

But that is not the best part, we will not configure React on our own, but rather let the crowd favorite CRA do it for us. CRA (Create-React-App) will not only abstract out all the webpack config files, but will also make sure your react dependencies stay updated. This will help in keeping your code up to date in the long run.

2. Python

The task that is being performed by Python in our case was inevitable and could not be performed by JavaScript because PSLab only had Python libraries. We did not have the time to write everything again for JS so we figured a way to make use of Python in the electron app. If you can do everything with JS and have the necessary libraries to do so, then you don’t need this. For example, if you need to predict some value using a model you trained via TensorFlow, then this would be one such use case.

Bear in mind that this could be extended to any language as long as you get your hands on a library that can deal with the communication.

3. Electron

In short, it gives you the platform to make use of the above two. It becomes more interesting when we go into the details of how electron works. But for now, let us just say, it will provide you the space on which react will render the UI, it will provide the means for your UI to talk to the Python code, it will also provide APIs to talk to native system features like filesystem, notifications etc.

Resources:How to build an Electron app using create-react-app. No webpack configuration or “ejecting” necessary. Christian Sepulveda Christian Sepulveda: https://medium.com/free-code-camp/building-an-electron-application-with-create-react-app-97945861647c

Settings page in SUSI.AI earlier implemented using Flux needed to be migrated to Redux, Redux integration eases handling of global state management. With Redux being integrated with Settings, the code could be split into smaller manageable components. Earlier implementation involved passing data to other Settings Tab and using Settings component as a state source. This resulted in Settings component getting more lines of code(~1300 LOC). After using Redux, only ~280 LOC is present in settings component file, and separate files for each settings tab view. 

Code Integration

Once user login, the App component fetches User Settings in ComponentDidMount.

componentDidMount = () => {
   const { accessToken, actions } = this.props;

   window.addEventListener('offline', this.onUserOffline);
   window.addEventListener('online', this.onUserOnline);

   actions.getApiKeys();
   if (accessToken) {
     actions.getAdmin();
     actions.getUserSettings().catch(e => {
       console.log(e);
     });
   }
 };

src/App.js

The action getUserSettings fetch users settings from apis.getUserSettings and populates the store settings using SETTINGS_GET_USER_SETTINGS reducer function.

Default States:

The store consists of all the settings required for persisting data.

 const defaultState = {
 theme: 'light',
 server: 'https://api.susi.ai',
 enterAsSend: true,
 micInput: true,
 speechOutput: true,
 speechOutputAlways: false,
 speechRate: 1,
 speechPitch: 1,
 ttsLanguage: 'en-US',
 userName: '',
 prefLanguage: 'en-US',
 timeZone: 'UTC-02',
 customThemeValue: {
   header: '#4285f4',
   pane: '#f3f2f4',
   body: '#fff',
   composer: '#f3f2f4',
   textarea: '#fff',
   button: '#4285f4',
 },
 localStorage: true,
 countryCode: 'US',
 countryDialCode: '+1',
 phoneNo: '',
 checked: false,
 serverUrl: 'https://api.susi.ai',
 backgroundImage: '',
 messageBackgroundImage: '',
 avatarType: 'default',
 devices: {},
};

reducers/settings.js

Reducer action:

SETTINGS_GET_USER_SETTINGS sets the settings store from API payload. The customThemeValue is an object, which is populated once the settings are fetched and the string is split into array.

[actionTypes.SETTINGS_GET_USER_SETTINGS](state, { error, payload }) {
     const { settings, devices = {} } = payload;
     if (error || !settings) {
       return state;
     }

     const {
       theme = defaultState.theme,
       server,
       ….
       avatarType,
     } = settings;
     let { customThemeValue } = settings;
     const themeArray = customThemeValue
       ? customThemeValue.split(',').map(value => `#${value}`)
       : defaultState.customThemeValue;
     return {
       ...state,
       devices,
       server,
       serverUrl,
       theme,
       enterAsSend: enterAsSend === 'true',
       micInput: micInput === 'true',
       speechOutput: speechOutput === 'true',
       speechOutputAlways: speechOutputAlways === 'true',
       speechRate: Number(speechRate),
       speechPitch: Number(speechPitch),
       ttsLanguage,
       userName,
       prefLanguage,
       timeZone,
       countryCode,
       countryDialCode,
       phoneNo,
       checked: checked === 'true',
       backgroundImage,
       messageBackgroundImage,
       avatarType,
       customThemeValue: {
         header: themeArray[0],
         pane: themeArray[1],
         body: themeArray[2],
         composer: themeArray[3],
         textarea: themeArray[4],
         button: themeArray[5],
       },
     };
   },

reducers/settings.js

Updating Settings

Reduce function:

The payload contains the updated state, the reducer returns a new state with payload appended.

setUserSettings: createAction(
   actionTypes.SETTINGS_SET_USER_SETTINGS,
   returnArgumentsFn,
 )

reducers/settings.js

Action:

The setUserSettings action updates the settings store, once the user presses the Save Button in the Settings Tab.

function mapStateToProps(store) {
 return {
   enterAsSend: store.settings.enterAsSend,
 };
}

actions/settings.js

Redux integration in the component

Redux is used in ChatAppTab as: The local state of ChatAppTab is initialized with redux store state. Using mapStateToProps we can access enterAsSend object from the redux store.

The connect function connects the React component with Redux store and injects props and actions into our component using HOC pattern. It injects data from the store and functions for dispatching actions to store.

Injecting props in local components:

function mapStateToProps(store) {
 return {
   enterAsSend: store.settings.enterAsSend,
 };
}

components/Settings/ChatAppTab.react.js

Once a user makes a change in the tab and saves it, we need to dispatch an action to modify our prop enterAsSend inside the redux store. 

function mapDispatchToProps(dispatch) {
 return {
   actions: bindActionCreators({ ...settingActions, ...uiActions }, dispatch),
 };
}

components/Settings/ChatAppTab.react.j

handleSubmit = () => {
   const { actions } = this.props;
   const { enterAsSend } = this.state;
   this.setState({ loading: true });
   setUserSettings({ enterAsSend })
     .then(data => {
       if (data.accepted) {
         actions.openSnackBar({
           snackBarMessage: 'Settings updated',
         });
         actions.setUserSettings({ enterAsSend });
         this.setState({ loading: false });
       } else {
         actions.openSnackBar({
           snackBarMessage: 'Failed to save Settings',
         });
         this.setState({ loading: false });
       }
     })
     .catch(error => {
       actions.openSnackBar({
         snackBarMessage: 'Failed to save Settings',
       });
     });
 };

components/Settings/ChatAppTab.react.js

handleSubmit is invoked when user presses the Save Button, action.setUserSettings is dispatched once API returns accepted: true response.

To conclude, the removal of flux and integration of redux gave the advantage of making the code more modular and separate the logic into smaller files. In the future, more settings can be easily added using the same data flow pattern.

Resources

• Migrating to Redux from flux: https://redux.js.org/recipes/migrating-to-redux
• Why use Redux- https://blog.logrocket.com/why-use-redux-reasons-with-clear-examples-d21bffd5835/
• Documentation of Redux – https://redux.js.org/
• React Anti-Pattern: Prop-Drilling – https://codeburst.io/react-anti-pattern-prop-drilling-54474d5236bd
• Redux connect – https://react-redux.js.org/api/connect
• Link to the PR: https://github.com/fossasia/susi.ai/pull/2129

Tags

SUSI.AI, FOSSASIA, GSoC19, Redux, SUSI Chat, Settings