Users Admin

[thomporter]

I would like to make some changes to the admin, I thought I'd open a discussion on them as I have a lot in mind:

• Move the users admin to it's own url: /admin/users
• Create generic admin home page
• Add pagination to the user list (in the API & UI)
• Add search to users
• Add create user
• Add update user (including change password)
• Do it all via a directive (or perhaps a few nested directives.)

The first 2 changes listed above are big for me... My clients typically want something entirely different on their admin home page. They may want a small "widget" with the most recently logged-in or created users, but more often then not they want a summary of sales! =) Not so much anymore if it's just a directive. ;-)

The rest of the items are of less importance, but still, I do see it as something I'll have to copy & paste from project to project. =)

I would also consider adding more to the users, perhaps as a filter option in the generator, "Create Extended User Model (phone, address, etc.)?" Typically most of the sites I build the client wants this sort of thing.

[JaKXz]

@thomporter I think your first point is a matter of opinion, because I like the admin url where it is. I do like the rest of your points and would love to see all that implemented 👍

[thomporter]

The first and second bullet point are related [edit: ie, no need for generic home page if you're not moving the users to it's own page in the admin...] Or is that what you mean by "first point", the ones I call "big"?

[JaKXz]

I apologize, I did mean your "big points". Specifically,

Create generic admin home page

I think (please correct me if I'm wrong) this implies updating the UI to a certain spec. That would be great, but I don't think that everyone would like one particular spec, so I'd leave it to developers/designers to create what they want.

However, I would love to see the functionality mentioned in the rest of your points. Pagination would be fantastic, search is easy to implement, and create/update should be relatively easy also 😄

[thomporter]

Well, the same could be said about using /admin - that's a decision on the spec... I'd also add that what I'm suggesting is making the user's admin a "module", put all of the files in a folder (called "users" in the admin folder) and then give it the url /admin/users. If a dev wants to change the URL & move the files, they can... But I still feel like making the user's admin it's own module is worth-while...

Love the pagination directive, I'll use that for sure. =)

[JaKXz]

Having /admin as the generated route/state for the admin page seems logical to me because, in my head, the admin 'console' or 'dashboard' in its most basic form (i.e. what the generator gives you) is one screen that does everything with separate divs that have all the subpages' content.

I see your point about breaking it down into /admin/users, and e.g. for a blog-type app /admin/pages, and /admin/stats etc. which is entirely up to you to implement if you want to.

What I'm trying to get across is to have the features that you keep copying over for every project in the PR. But like you said, the breakdowns can vary from project to project, if there are any at all... perhaps the /admin/users page would serve as a good example.

[kingcody]

IMO sounds like a job for UI-Router and nested states. I think you could easily accomplish what you're looking for with that. You can define your custom urls as relative or absolute if you like, have multiple views in parallel or as children, and a lot of other cool stuff. I think it could work. As a bonus you could tie into the socket update framework laid out and keep your users' info up to date in real time ;)

[thomporter]

Oh yeah, UI-Router & nested states for sure, but I think we'd have to support ngRoute too, no?

[kingcody]

Oh, you meant in the generator. My mistake, I thought you were referring to your implementations. I have an idea for a compromise between your thoughts and @JaKXz.

What if instead of a full blown page for /admin/users we instead create a directive or a small set coupled together that is included on the /admin page, along with any other directives/sets needed to provide additional admin features. I feel like this would provide maximum reusability and allow users to easily switch where the directives are displayed at; ie. /admin or /admin/users, /admin/....

[JaKXz]

Ack, I meant directives, thanks @kingcody.

[kingcody]

As a bonus (maybe) this could serve as a demonstration to new users the power of angular's directives and some best practices for modularizing code/functionality?

[thomporter]

Directives sound like a great plan. In which case, I don't mind just having the generated admin home page just include the directive, that's super simple to move if needed. Good call!

[kingcody]

@thomporter, I actually really like the idea of nested views and allowing restful URL routing with $stateProvider and I'll most likely be using that idea (thank you!) in my projects as well. I just feel like its a bit specific for the generator, at least at this time. Especially as you mentioned, it would be much harder to implement that with ng-route.

[thomporter]

@kingcody indeed, w/ the directive plan, I'm just not that worried about it now! =)

[thomporter]

I updated the original comment to reflect the current consensus.

Curious about thoughts on the last point I make in the original comment, about offering an extended user model with addresses & phone numbers (both being arrays of sub-models.) I suppose @JaKXz gave a thumbs up in his original reply, but IDK, later he specifically called out other stuff he loved the idea of, but not that, so I thought I'd be sure! 😇

[JaKXz]

@thomporter go right ahead! In truth I just wanted to point out the pagination directive.

[thomporter]

My proposed extended user model, with address & phone numbers: (any comments?)

<% if (filters.extendedUser) { %>
var AddressSchema = new Schema({
  type: { type: String, required: true},
  street: { type: String, required: true},
  city: { type: String, required: true},
  state: { type: String, required: true},
  zip: { type: String, required: true},
  country: { type: String, required: true}
});
var PhoneSchema = new Schema({
  type: { type: String, required: true},
  number: { type: String, required: true }
});
<% } %>

var UserSchema = new Schema({
  name: String,
  role: {
    type: String,
    "default": 'user'
  },
  username: String,
  salt: String,
  hashedPassword: String,<% if (filters.extendedUser) { %>

  addresses: [AddressSchema],
  phones: [PhoneSchema],
  <% } %>

  credentials: [ CredentialSchema ]<% if (filters.oauth) { %>,

  //  NOTE: using `Mixed` is tricky. Should be changed to sth else.
  strategies: {
    type: Schema.Types.Mixed,
    "default": {}
  },
  localEnabled: {
    type: Boolean,
    "default": false
  }<% } %>
});

[gardner]

When implementing extended user profiles, please consider reading up on the Portable Contacts specification which is used by passportjs. Thank you.