amplication/amplication

🔥🔥🔥 Open-source backend development platform. Build production-ready services without wasting time on repetitive coding.

amplication's Issues

cannot resolve Entity.fields on Entities Page

Create symbols

Convert the presentation with the new branding

Split ResourceBasedAuth Decorator

@iddan, as per out talk -
please split the decorator and create two seperate decorators. suggested names:

InjectContextValue Decorator
ContextAuthorize Decorator

Prototyping

Expression Resolver

Use classes instead of json schema

@iddan
I think we should consider to use classes with validation attributes (like all other model classes) instead of using json schema for all json fields.

in the current scenario (entity field properties) where we are dealing with just simple fields the json schema works well. But looking ahead on the pages and other very complex structures that we use json for I think json schema wont be enough.

I assume that when we'll build the ui editor or any other block like Connector, we will anyway use classes to describe the object - so we may as well use the objects to validate the request and more.

what do you think?

Unique constraints should be case insensitive

Current the Unique Keys (e.g. EntityField,Name) are case sensitive and the user can create two fields with identical names with different casing (e.g. "AAA" and "aaa").

GraphQL naming conventions

We should revisit all mutations and queries in graphQL and rename then with the entity name first and then the actions.
Instead of
createEntityField or CreateOneEntityField
we should use
entityFieldCreate

Instead of
createOneEntityVersion
we should use
entityCreateVersion or entitySaveVersion

@iddan, I know that with graphQL it is usually recommended to use the action first, but i dont like it. What do you think?
See this post for more info
https://www.apollographql.com/blog/designing-graphql-mutations-e09de826ed97

create Amplication letterhead

Add more "amplication" purple

API Page

amplication.com website

Add timeout to GitHub action

Currently, it times out after 6 hours. It should time out after 15 minutes.

open issues for discussion in next sessions

We should use this issue to track items for open discussion in any of the future sessions:

• How to create API endpoints for actions that are needed in screens. Should we automatically create the API with all the requested features? should these API be editable in the APIs section? should we use the same roles from the page on the API?

DB migrations process and best practices

we need to set a process on how to use prisma migrations.
Too often we have conflicts and need to hack around it.
There are probably best practices that can help us.
We should also think of how to use it later down the road on production to update live DBs.

@iddan if you have any input please share

Entity Page - Client Side (w/o preview)

The app list is not updated after creating a new app

Create a new app, the go back to the app list - the new app is not listed

Create Email Signatures

UI - Entities Page - Option Set

@LeeAmp
I created a new page in Figma called "Option Set" with an example of how the UI should looks like when creating a new option set.
Please merge the functionality into the main Figma page

App Publisher

App Generator

App Code Generator

Entities page - The properties panel is not updated when selecting a field

When you select a field for the first time the properties panel opened and all values are correct, but when you click on another field while the panel is already open, the values of the new fields does not updated and you still see the values of the previously selected field

"Name" Fields validation

Entities and Entity Fields have a Name and a Display Name.
The Display name is used for display purposes throughout the system. The Name field is used for code and reference purposes.
for example, when a developer wants to assign a value from the Last Name field to the First Name field he will use the Name property in the following way:
customer.FirstName = customer.LastName

We should add validation both on the server side and client side for the correct format.

1, Choose format to be used (no spaces, dots, and such). Is there any common format for such fields?
2. Implement this on the server side (decorators with regex on the model? in the service?both?)
3. Implement this on the client side

Entities Page - Behaivour

• The side panel should always stay open and visible.
• When creating a new Entity Field, all the properties on the screen should show a default value (e.g. max length)
• A text field should be available on the entity box to add new fields without using the side panel
  • the user clicks on the + sign
  • a textbox is shown on the entity box, while the side panel shows a "new field" state.
  • The user types in the field name and clicks on Enter (he can also use the side panel for full features)
  • The new field is created with default values
  • The focus remains on the textbox to allow the user to create more Fields
• when the user types in a new entity name, the display name should be automatically created with spaces based on CamelCase format.
  The same for entities, including Plural Display Name.
• the Name field should only be limited to a specific set of characters. no spaces, no dots, etc (TBD)

App Versioning (build, rollback…)

Entity Permissions - Client Side

Schema Validation

When saving entity fields, or blocks, or pages we need to save a list of properties in a JSON field in the DB.
We should validate the JSON schema before we save it to the DB.
for example:
EntityField.Properties is a JSON field that holds the special properties for each dataType.
When data type is "Single Line Text" the properties should only include "Max Length"
When data type is "Whole Number" the properties should include "Min Value" and "Max value".

In order to do that we can use a JSON schema validation package

https://github.com/tdegrunt/jsonschema
https://github.com/ajv-validator/ajv
https://github.com/ebdrup/json-schema-benchmark

for each datatype we should have an hard-coded schema and use it both on the client side and server for validation and presentation.

Client Generator

Spec: https://www.notion.so/amplication/Generating-Admin-UI-Code-8f2cb498da6d42f6ba3ff23ace030f3e

Testing module - complete spec

UI - Roles

See the "Roles" page in Figma

Entity Page - Roles & Permissions

Data Service Generator

Decision table

Add cache to GitHub action

https://help.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#using-the-cache-action

Try different shades of the palette

Pages screen + UI Editor - Phase 1 - Spec

Should we add built in fields for all new persistent entities?

When a user create a persistent entity, should we add built in fields?

id
createdAt
updatedAt

Pages screen +UI Editor - Phase 2 - Base Design

Docker Build Service

remove Is Persistent from the UI

The field IsPersistent determine whether the entity represents a table in the DB or just a DTO.
This is actually done using to different types of "entities" in the UI - Entity and Structure.

When the user creates "Entity" the field IsPersistent equals True
When the user creates "Structure" the field IsPersistent equals False

Login out and Logging In With Another Account Doesn't update the Account

Restructure server code - use a folder per module/feature

-- src
-- featureName (folder)
-- featureName.ts (model)
-- featureName.module.ts
-- featureName.service.ts
-- featureName.resolver.ts
-- DTO (folder)
-- featureDto1.ts
-- featureDto2.ts
-- featureDto3.ts

Entity Fields - Complete Validations for all types

Entity Page - Server Side

Try reveres dark mode

REST API Connector and OpenAPI spec

I found this project with types for OpenAPI documents.
https://github.com/kogosoftwarellc/open-api/blob/master/packages/openapi-types/index.ts

Theoretically we could use these types to create and save the configurations for our REST API Connectors but there are few issues:

1. GraphQL will not allow Union Types in the Input and many of the OpenAPI types are Union types.
2. Our configuration includes several extra functional features like "context parameters", permissions and visibility per specific fields and more....

For the above reason, I suggest that we use our own types to create REST API Connectors and only in runtime or build time we will convert our types to OpenAPI schema.

@iddan, your thoughts pleases

Invalid Password throws an Error instead of just trigger the UI

Prisma Generator