Administrator model customization

[mdibaiee]

Describe the bug
Currently it seems it's not possible to create relations with the Administrator model (one-way).

An example use case:
We have a plugin in which we want to create new entities of a certain type, but we also want to know which administrator created them, so we would like to save a relationship between this entity and administrator. This can be a one-way relationship, but it seems even that is not possible.

Steps to reproduce the behavior

1. Create a model
2. Create a relationship with administrator:

"created_by": {
  "model": "administrator",
  "plugin": "admin"
}

3. Run project
4. See error

Expected behavior
Ability to create relationships (even if one-way) to administrator

Screenshots
N/A

Code snippets
N/A

System

• Node.js version: v10.2.1
• NPM version: 5.6.0
• Strapi version: 3.0.0-beta.2
• Database: PostgreSQL
• Operating system: Archlinux

Additional context
N/A

[derrickmehaffy]

Agreed, @lauriejim this is also related to what I mentioned to you in slack about overriding the admin model file

[alexandrebodin]

Hi,

I agree with you it would be a nice feature to have.

Right now you can implement your usecase by using the user from the users-permissions plugin (I know it means having duplicates of your admins in the users) but this will at least allow you to implement until this feature is implemented somehow.

@derrickmehaffy @mdibaiee What kind of relations would you like to have ?

[cschweda]

I have a similar issue with the new way the admin is configured.

My use case

We have an in-house, agency calendar. Users must sign in to view the calendar. The sign in authentication is handled by Strapi.

Until recently, the calendar user's roles were either Strapi 'Administrators' or Strapi 'Authenticated'. There is no 'Public' access to the calendar. Users registered via a registration link (the registration process handled by Strapi) -- and a successful, email verified registration meant you were automatically set as 'Authenticated'.

If your Strapi user role is 'authenticated', you're only able to view the calendar. If, however, your Strapi user role is 'Administrator', you're able to view the calendar as well as make edits to the calendar via the Strapi admin back-end. A unit manager would say, hey, so-and-so needs to edit the calendar as well as view the calendar. When I got this request, I manually bumped the user's role from 'Authenticated' to 'Administrator' -- and then I'd send that new 'Administrator' user a link to the Strapi admin.

The point here is that both 'Authenticated' and 'Administrator' users used the same login process -- go to the registration link on the front-end, register, verify e-mail, and then login via the /auth/local. The best part of this is that the user -- no matter if she were 'Authenticated' or 'Administrator' could use the same username and password for access to the back-end Strapi admin and the front-end calendar app (written in Vue)

What's happening now

Now, 'Administrator' roles have to be authenticated via /admin/auth/local on the front-end whereas 'Authenticated` users authenticate via /auth/local.

The issue

So the issue right now is that those admin users can't simply login to the calendar anymore. The /auth/local route won't authenticate them. They need a seperate username/password to access the Strapi backend. So they'll have two username/password combos -- one to access the Strapi back-end, another to access the 'front-end'.

Confusion

So, I'm confused now. I'd been using the single route to login. Now there's two routes. So either I need to create sepeate usernames and passwords -- or I ask the user up front: are you an admin? Are you a user? ... and then set the auth route accordingly.

My questions:

• How can I set an 'administrator' role so that she's able to log in to the Strapi back-end and my app front-end with the same username and password?

• I no longer see the 'administrator' role in my content type user relation. So, if say, a person is a Strapi admin and an authenticated Strapi user -- their username needs to be in both the 'Admin' role as well as the 'authenticated' role in order to see it in the user-relation dropdown on a content-type (and, say, add that user to a blog post or article or whatever.)

• Even if I create a brand new custom role -- and click every box for the permissions -- that new role isn't able to access the Strapi admin. I want a simple checkbox to say, okay, can this user access the Strapi admin? If yes -- click it and grant access. That's it. That seems like the simplest solution.

I understand the desire to seperate the strapi roles from the app roles -- but in my case, and (I suspect) many others -- the roles are identical. An 'admin' is an 'admin', 'root' is 'root', 'superAdmin' is 'superAdmin' -- so she should be able to log in to the strapi backend and login to the app front-end -- all with the same username and password.

The alternative, of course, is to create a brand new back-end UI -- essentially duplicating Strapi's admin -- and granting that custom user (or 'authenticated' user) access to my custom back-end UI -- and then just using Strapi as a way to handle GET/POST requests.

But this backend UI and baked-in authentication was exactly the reason why I started using Strapi in the first place. :)

[mdibaiee]

@alexandrebodin currently, our use case is just a one-way relationship to the administrator model.

We want our local plugins to be able to create models, which, as a metadata, include the Administrator which created them in their database record. So our table looks like this:

{
  "connection": "default",
  "collectionName": "sms",
  "info": {
    "name": "sms",
    "description": ""
  },
  "options": {
    "increments": true,
    "timestamps": true,
    "comment": ""
  },
  "attributes": {
    "created_by": {
      "model": "administrator",
      "plugin": "admin"
    },
    "body": {
      "type": "string",
      "required": true
    },
    "retailer": {
      "model": "retailer"
    },
    "users_count": {
      "type": "integer",
      "min": 0
    },
    "created_at": {
      "required": true,
      "type": "date"
    },
    "updated_at": {
      "required": true,
      "type": "date"
    },
    "deleted_at": {
      "required": false,
      "type": "date"
    }
  }
}

If I understand correctly, the only change I'm looking for right now is the ability to specify admin as the plugin (or any other type of change) to use the model.

If you can point me to where the code for this resides, I might be able to create a pull-request myself.

As a next step (and I can foresee this requirement), I think we potentially will want to customize the administrator model as well.

[alexandrebodin]

Hi guys.

Here is how I think the admin / user-permissions should work in the future so we can discuss the short term wins we can have:

User-permissions

The idea is to make the user-permissions plugin a real oauth / open id connect server and use passportjs to allow for a lot of providers.

Admin connection

In the same way I want the admin to use passport so people can configure it to connect to the users-permissions plugin if you want to. Use a ldap or any other passport providers.

What do you guys think about it ?

[alexandrebodin]

For the fields/columns customization it is a much simpler usecase. You can already custmize it by make the updates in the model directly in your bootstrap function.

[derrickmehaffy]

For the fields/columns customization it is a much simpler usecase. You can already custmize it by make the updates in the model directly in your bootstrap function.

@alexandrebodin Probably should elaborate on this for over-riding the model.

[alexandrebodin]

You can add custom fields attributes (⚠️ not relations ⚠️ ) by creating a custom hook.

Make sure to put run it first by updating the config in

config/hook.json

{
  "timeout": 3000,
  "load": {
    "before": ["custom-hook"],
    "order": [
      "Define the hooks' load order by putting their names in this array in the right order"
    ],
    "after": []
  }
}

hooks/custom-hook/index.js

const _ = require('lodash');

module.exports = () => {
  return {
    initialize(cb) {
      _.merge(strapi.admin.models.administrator, {
        attributes: {
          randomColum: {
            type: 'string',
          },
        },
      });

      cb();
    },
  };
};

We either can allow modifiy the model via json like the other and in the interface but this will make the possbile errors too important in my opinion.

I would like to provide and fairly simple api to customize a model on startup.

example:

strapi.models('administrator').extend({
  atttributes: {
    newField: {},
    newRelation: {},
  },
});

[derrickmehaffy]

@alexandrebodin what about modifying existing values? Such as these:

strapi/packages/strapi-admin/models/Administrator.settings.json

Lines 2 to 6 in 15daa62

	"connection": "default",
	"collectionName": "strapi_administrator",
	"info": {
	"name": "Administrator",
	"description": ""

[derrickmehaffy]

And for example what if someone wants to modify their services/controllers of the admin package?

IE: https://github.com/strapi/strapi/blob/master/packages/strapi-admin/services/auth.js

I'm more for the opinion that the admin package needs to be split, one for the UI, the other should be an authentication plugin similar to users-permissions

[derrickmehaffy]

(or convert the whole admin package itself into a plugin)

[alexandrebodin]

you can change any meta with the example I provided. At your own risks.

I really don't think people should modify the controllers or services. Extending the model makes sense. Providing some programtic extension points too but just changing the files is really the best way to allo people to break everything at anytime. It doesn't really scale.
If it is missing features I would rather have them start a conversation and make a PR so it helps not only them but the community. Alllow people to just overwritte any files kinda break the idea of making Strapi open source as no one would need to contribute back to it 🤔 I guess it is a matter of opinion anyway.

[derrickmehaffy]

@alexandrebodin

Alllow people to just overwritte any files kinda break the idea of making Strapi open source as no one would need to contribute back to it

I would like to point out that realistically Strapi should for easy customization in all aspects, this should include options for all packages as not everyone's use-case is going to follow "the heard", and there is going to be some niche cases. As an example extending the admin authentication to add certain password, username, email restrictions. Maybe specific password polices, the options are limitless and hence the reason I think that admin package needs to allow for this.

If we are allowing users to modify the "frontend" of the adminUI, the backend should have the same respect.