kot13 / bootstrapi Goto Github PK

Hi,
I'm trying to use your framework but I've an issue i do not understand.
I've added all classes and configurations about two entities:

• company
• advertiser
  Company has one row on database and when I call GET method I've this output:
  { "errors": [ { "status": "500", "code": "500", "title": "Internal server error", "detail": "Trailing data" } ] }
  Advertiser table was empty and result was data[], after inserting one row, the same error happens.
  The same doesn't happen with the User table created by framework.
  Can you please drive me on finding the issue.

Thanks,
Maurizio

SUPPOSITION

We have one main/meaningful entity provided by bootsrapi - USER. All the rest entities are either auxiliary for user operations (e.g. *_tokens, roles, rights, roles_to_rights) or system maintenance (e.g. migrations, seeds, ,logs). This is nice as a starting point at the very beginning. However, this is not enough even for a decent scaffolding.

PROPOSITION

Let's introduce additional general-purpose entity, reasonably called ENTITY :) and some auxiliary/boilerplate entities in order to provide complex relations between entities and users. Proposed entities are:

ENITITY
--------
id BIGINT
type INT
status INT
owner_id BIGINT foreign key -> users.id
connector_id BIGINT foreign key -> connectors.id
attributes JSON

Entity represents arbitrary entity, owned by a USER (via owner_id) and having arbitrary set of attributes.

CONNECTOR
--------------
id BIGINT
type INT
owner_type INT

Connector represents 'connection point' designed to provide relations between custom entities in the system (like entity <-> entity or user <-> entity, etc). Each entity in the system who intends to establish relations provides its 'connection point' - connector in order to receive or to establish relations.

RELATION or may be called CONNECTION - named relatively to CONNECTOR above
-----------
id BIGINT
connector_id_a BIGINT foreign key -> connectors.id
connector_id_b BIGINT foreign key -> connectors.id
type INT
status INT
attributes JSON

Intended to setup a relation between two entities via their CONNECTORs

Possible relation/connection types:

1. b is owned by a
2. b is member of a
3. b is assigned to a
4. b is child of a
5. ... etc ...

Also new attribute in USER entity would be needed - connector

USER
====
... all known fields
connector_id BIGINT foreign key -> connectors.id

Proposed structure would allow to build custom relations between all entity types in the system, opening direct way to construction of entity hierarchies owned by users, attach entities to another entities or users, etc

Imagine the following structure:

1. entity of type 'event'
2. entity of type 'collection'
3. multiple entities of type 'note'
4. relation 'event'-'collection' of type 'owned'
5. relation 'note'-'collection' of type 'assigned to'

And as a result, we'll have 'event' with a 'collection' of 'notes' build on custom entity base.

PS. I can implement proposed update

SUPPOSITION

It would be nice to have external auth (via Facebook, VK, OK, etc) support

PROPOSITION
Let's introduce support for external auth.
We can add new entity

auth_external
=============
id BIGINT
source STRING
source_user_id STRING
user_id BIGINT foreign key -> users.id

where
source - name of the external auth source, like FB, VK, etc
source_user_id - user id provided by external source
user_id - reference to local user

PHP support for popular auth sources is required as well.

PS. I can implement proposed update

Hi,
I'd like to have some suggestions about this use case:
I've an entity Company, Users belongs to a Company with a relation 1-N
I also have an entity Offers, users create offers and must be related to the company of the user creating it. At the same user getting offers must receive a list of offers belonging to the user's company.
So ideally I'd like to have that users that have role "user" don't need to declare the company_id of belonging when creating/getting an offer, on the opposite if the user has a role "admin" the company_id must be passed in parameters.

So first questions are:

• is there a way to declare a field as mandatory or not based on the user role?
• how can I automatically add in the Offer actionCreate the company_id based on the user logged?

Thanks,
Maurizio

If foreign key constraint for user_id is added in access_tokens table, shall it be an additional overhead when there are large number of users. I am asking this because, when I add foreign key constraint to user_id field, the index on it is removed, and indexing is for sure, good when there are large number of users. Or is it that adding a foreign key constraint to a column is automatically indexed.

So what to use, foreign key constraint or index for user_id?

SUPPOSITION
bootstrapi has configuration files located in config folder and separate setting.php.

PROPOSITION
Let's use Config component from Symfony - this would help to unify all configurations and unify approach to config settings. Proposed component - Config

PS. I can implement this

Hello Pavel!

It would be nice to unify username/email attribute usage throughout the API. We have the following situation at the moment:

POST /user (create new user)

{
    "data": {
        "attributes": {
            "full_name": "Тестовый пользователь",
            "email": "[email protected]",
            "password": "qwerty",
            "role_id": 1,
            "status": 1
        }
    }
}

we have email attribute used during user creation process, while we have to provide username attribute in order to obtain token

POST /token

{
    "data": {
        "attributes": {
            "username": "[email protected]",
            "password": "qwerty"
        }
    }
}

This looks like inconsistency between two related requests.

PROPOSITION:
Let's add new attribute username to user description and leave email as it is as an auxiliary attribute for now. In future this email attribute can be extracted into separate entity like user profile or something. Username can be either email or phone or ASCII-string. Char filtration should be added, of course
Proposed 'create user' request:

POST /user (create new user)

{
    "data": {
        "attributes": {
            "username": "[email protected]",
            "password": "qwerty",
            "role_id": 1,
            "status": 1
            "full_name": "Тестовый пользователь",
            "email": "[email protected]",
        }
    }
}

all the rest user-related requests should be updated as well, of course.

I can implement this change after we'll agreed on modifications.

Please, add composer.lock to fix dependencies' versions and save it in control state.

And delete it from .gitignore

SUPPOSITION
App\Model\AccessToken and App\Model\RefreshToken are very much the same - the main difference is inside createToken()

PROPOSITION*
Let's extract common functionality into new App\Model\Token class and rework RefreshToken and AccessToken to be children of Token

PS. I can implement this

Рассматривался ли вариант, что не всегда есть возможность править конфигb nginx?
вероятно стоит добавить в ваш проект вариант с .htaccess

SUPPOSITION
Sometimes it is required for users to shape some kind of hierarchy. For example: group-group member relation or senior-junior relation. There are no support for user hierarchy in bootstrapi at the moment.

PROPOSITION
Let's introduce support for user hierarchy/relations for bootstrapi.
We can add new entity

user_relation
=============
id BIGINT
type INT
user_id_a BIGINT foreign key -> users.id
user_id_b BIGINT foreign key -> users.id
status INT
attributes JSON

Relation between users could be one of:

1. b created by a
2. b is a group member
3. a invitation located in attributes.data.invitation
4. ... etc ...

Support for 'many-to-many', provided by external relations table, would allow, for example, to join users into multiple groups.

PS. I can implement proposed update

There already is an issue for misleading naming 'email' vs 'username' here. Let's make it unified and use generalized 'identity' field for token request. In this 'identity' fiend can really be whatever identity can be acceped - username, email, phone etc.