ertugrulozcan
commented
5 months ago Naming: Typically, migrate is understood to be the importation of data in bulk. The current migrate endpoint provides inputs for one membership, one user, and one application (as an aside, the application input appears to be mandatory as well, but not optional as the README states), so I think the functionality of this endpoint is more of an initiate by its very nature.
Prerequisites: The previous (March 21 when I tested it) version of the migrate did not need to provide the secret_key and slug for the membership, both of which can be generated automatically. A recent test found that both of these and the default_language have become required while "migrating", not sure if this is a newly created bug in a code update or a change in design thinking?
Transaction (not really an issue but concern): This may be because some of the validations are at the API level and some are at the CRUD level. the Application passes the API level validation, but fails the CRUD level validation (the role name is incorrect). However, both Membership and User have already been written in the database, and a default role admin is also created.
At least one membership and at least one user must be created for ErtisAuth to be ready for use. (Therefore, at least one role must also be created) Just as ErtisAuth performs the authorization control of any resource of application through its roles, it also performs the authorization control of its own resources (user, application etc) with the same mechanism. At this point we encounter a problem. How can we authorize the creating of these initial resources when there are no memberships, roles and users yet in the initial installation? The "migrate" endpoint was developed to provide a solution to this problem. Authorization control is ensuring with the database connection string on the header. After the first membership and admin role users are created, all other resources can be created via the API. So, the term "migrate" does not mean bulk import. However, you may be right about the naming, perhaps it would have been better to choose "initiation". I will also examine the other validation problems you experienced during the test first chance i get. Thanks for your valuable feedback.
Naming: Typically, migrate is understood to be the importation of data in bulk. The current migrate endpoint provides inputs for one membership, one user, and one application (as an aside, the application input appears to be mandatory as well, but not optional as the README states), so I think the functionality of this endpoint is more of an initiate by its very nature.
Prerequisites: The previous (March 21 when I tested it) version of the migrate did not need to provide the secret_key and slug for the membership, both of which can be generated automatically. A recent test found that both of these and the default_language have become required while "migrating", not sure if this is a newly created bug in a code update or a change in design thinking?
Transaction (not really an issue but concern): This may be because some of the validations are at the API level and some are at the CRUD level. the Application passes the API level validation, but fails the CRUD level validation (the role name is incorrect). However, both Membership and User have already been written in the database, and a default role admin is also created.