A boilerplate Vuetify project which includes things like a repository layer, localization and dynamic entity components to allow for Rapid Application Development and prototyping.
Add address field type to system which should also include the geolocation of the address. Everything needed to reach/delivery the exact location provided.
Create a wiki page to explain how to translate system works and where to add new translations for new languages, and how to override base translations for existing language phrases
In computing, WYSIWYG, an acronym for What You See Is What You Get, is a system in which editing software allows content to be edited in a form that resembles its appearance when printed or displayed as a finished product, such as a printed document, web page, or slide presentation.
A WYSIWYG field will allow the user to edit displayable content in the administrative section. Very useful for extending platform capabilities or content via the database.
We could benefit from having a generic inbox component built into the system, which would allow us to have a more intuitive interface for managing email messages.
Component setup psudo:
Use an interface similar to Gmail to ensure user familiarity which should improve the user's experience with the component.
Figure out how to create a datetime field type in the system. Currently I think we should split this into two fields, one for date and one for time.
Note that we will be removing date and time fields from system in a future ticket so don't spend any time on these. Only implement the datetime field type.
We could benefit from having a generic calendar component build into the system, which would allow us to have a more intuitive interface for managing time based events.
Create a wiki page that will explain how to stub out repository API calls with local code. This is used to very rapidly create a prototype of a system without even needing a any server-side services or even a single server for that matter.
Handle Timezones In DateTime Display/Posting Layers:
We need to ensure that we always account for timezones when working with date/time/datetime to ensure internationalization compatibility. The trick here is to know both local time and international time, to ensure we don't loose meta information, for example: when setting flight times we need to know the local time in order to determine day/night hours.
To this point we should remove "date" and "time" type fields and only support "datetime" fields.
Maybe we should introduce some additional settings for datetime fields, like: explicit-timezone which will force users to set a timezone.
Add money field type to system which should also include currency, precision, normally 5 based on international standards, and must be an int64 data type at it's core.
Can set precision lower, down to zero, for currencies like Zim dollars where cents are not applicable.