Portal for Scriptoria -- App Publishing Service
Clone or download
giancorzo Bugfix: Org settings make public by default toggle (#285)
* refacotring and bugfix

* removing try catch

* change returns

* bugfix/public-settings
Latest commit 38776e7 Nov 14, 2018


AppBuilder Portal

Build Status Crowdin


The appbuilder-portal is the portal frontend/backend for the Scriptoria project. This project provides software to automate the building and publishing of apps (and other related content) to App Stores and websites.

This process requires the coordination of user activites, project data, automated services, and administrative activities (e.g. managing App Store listings). The process is defined and managed by a DW KIT Workflow instance. The portal provides organization, group, user, project, and product management and provides access to users and organizational admins to interact with the workflow activities.

This process also requires management of resources to store project data (AWS CodeCommit), generate artifacts from project data (AWS CodeBuild), and store artifacts for distribution (AWS S3). These resources are managed by an instance of AppBuilder BuildEngine.

Special Thanks

For authentication and authorization services:

For localization management:

For error reporting:

For email notification delivery:


Building The Images

CURRENT_VERSION=$(git rev-parse HEAD)

# nginx
  docker build . -f Dockerfile.nginx \
    --tag "nginx-$CURRENT_VERSION" --target release

# api
  docker build . -f Dockerfile.backend \
    --tag "api-$CURRENT_VERSION" --target runtime-release

Running Locally:

docker run -p 8080:80 nginx-$CURRENT_VERSION
docker run -p 3000:7081 api-$CURRENT_VERSION


Database configuration

DWKit requires database scripts to be executed before running the backend

  • scripts/DB/PostgreSQL/DWKitScript.sql
  • scripts/DB/PostgreSQL/Workflow_CreatePersistenceObjects.sql

These seem to be idempotent, but we do not have a guarantee that they will remain that way.

The backend has a Entity Framework Core migrations script generated into the production docker image (created by source/Dockerfile.backend) and is run at startup (by source/run-api.sh).

If you need to rollback a production release that contains a new migration change, you can generate a rollback sql script by running the following command in the source/OptimaJet.DWKit.StarterApplication directory of the code current at production (that you wish to rollback):

dotnet ef migrations script --idempotent --output rollback.sql <FROM> <TO>

To get the <FROM> and <TO> values, run the following command in the same directory:

dotnet ef migrations list

For the <FROM> value, use the last migration. For the <TO> value, use the last migration in the point in the history of migrations that you would like to rollback to.


Common scripts are in the run file, so be sure to check that for reference.


./run up:build

# first time only, after up:build, separate terminal
./run bootstrap


./run yarn test
./run dotnet test

Test Debugging:

./run yarn test:watch:detached

Now Visit http://localhost:9876/debug.html to debug the tests, and run them individually.

Backend Notes

  • All endpoints should be behind an api/ path
  • Access to Auth0 Management API requires configuation which should not be checked into source control
    • Values should be stored in .env (which is in .gitignore)
    • Login to http://manage.auth0.com
    • Navigate to APIs -> Auth0 Management API -> Auth0 Management API (Test Application)
    • Get Client ID and Client Secret values
    • assign to following variables in .env
  • When configuring the Machine to Machine Applications, the scopes required are:
    • read:users
    • read:users_app_metadata
  • Bugsnag is used to log exceptions
    • Add BUGSNAG_API_KEY to .env

Frontend Notes

DWKitForm requires

  • react-data-grid-addons
  • semantic-ui-react
  • jquery


  • see if jQuery can be removed (~85KB)
  • see if optimajet-form can be smaller (~569KB)