Software for managing TLD domain auctions
- Run
bin/setup
- Configure database in
config/database.yml
according to your needs - Adjust configuration variables in
config/customization.yml
. - Run
bundle exec rake db:setup
By default, the application creates an administrator user account that should be used only to create new user accounts, and then deleted.
email: [email protected]
password: password
System provides auction API endpoint & self-health check API endpoint.
Auction center exposes list of current auctions as JSON api. Time reported in ends_at
and starts_at
are always in UTC.
Request:
GET /auctions HTTP/1.1
Accept: appliction/json
Response:
HTTP/1.1 200
Content-Type: application/json
[
{
"id": "1b3ee442-e8fe-4922-9492-8fcb9dccc69c",
"domain_name": "auction.test",
"starts_at": "2019-02-23T22:00:00.000Z"
"ends_at": "2019-02-24T22:00:00.000Z"
}
]
Documentation on health check API is available at project WiKi here.
There are certain settings stored in the database that are used for the application logic. For example, the currency in which all auctions are conducted. An administrator can change these settings in /admin/settings page.
To send out emails and perform other asynchronous tasks, we use a background processing with PostgreSQL as queue backend. To start an executor, use bundle exec rails jobs:work
.
Part of running the application according to EIS business rules includes creating new auctions at the beginning of the day. Jobs are scheduled outside of the application, as the exact times are no concern of the application.
Due to various regulatory requirements, all database tables are audited according to the following procedure:
- Changes in
public.users
table are recorded into audit.users. Audit recordsaction
old_value
,new_value
,recorded_at
time according to postgres time zone andobject_id
which corresponds to the primary key of data inusers
. - History of each object is visible in the UI for the administrator.
- Audit data is never deleted, even if the original object is. For example, if you destroy user with id
123
, it's history can still be accessed under/admin/users/123/versions
.
- Create a migration similar to AuditUsersTable
- Create a new audit model like Audit::User.
Make sure to set self.table_name to
audit.your_table
- Add auditable concern to administrator routes:
namespace :admin, constraints: Constraints::Administrator.new do resources posts, concerns: [:auditable] end