You can clone with
HTTPS or Subversion.
I've added custom fields to Profile (extending grails.plugin.nimble.core.ProfileBase) and User (extending grails.plugin.nimble.core.UserBase) classes (which were created by jack-be-nimble script), however I cannot quite figure out what is the right way to make these fields viewable and editable in the Nimble admin screens.
I'd like to reuse the Nimble admin screens to the degree possible, just adding the extra fields to them where applicable (some are references to other tables, to be presented as drop-downs), as I quite like the Nimble admin screens.
Probably some templates need to be copied from somewhere and overridden, or added to, but I cannot quite find where this approach is documented.
@JohnMurdoch Extended information tab on view user screen is intended to display additional fields for user and profiles. The template used is /templates/nimble/user/extendedinformation You can copy and modify the template to display additional fields, or create forms for additional fields.
Thanks, I managed to override /views/templates/nimble/user/_extendedinformation.gsp to show the fields and also /views/user/edit.gsp to add edit controls.
I haven't quite figured out what to do to make these new fields save to the database.
I did my own UserController which extends grails.plugin.nimble.core.UserController so I could just override the update(Long) method, but it seems it would be more proper to somehow add my custom fields to "nimbleConfig.fields.admin.user", but I don't see such config items in /conf/NimbleConfig.groovy.
Look at DefaultNimbleConfig
user = [
user = [
profile = ['fullName', 'email']
This are the fields that nimble will update.. all other form fields will not considered when saving/updating users and profiles from within nimble.
You can override this configuration, and add your extra field names in nimble.fields.enduser.user / nimble.fields.enduser.profile - if you want to allow this fields to update for admin users as well, put them in nimble.fields.admin.user as well.
Thanks, actually got some of this to work now if I put it under nimble.fields.admin.user !
nimble.fields.enduser.user seems to be ignored as UserController line 88 only considers the admin fields (at least in my version of the plugin).
Also, it would seem to make sense for the default edit screen to include full name and e-mail but it seems only the _extendedInformation.gsp includes it.
Apologies if I've missed something.
Right, nimble.fields.enduser.user is used only while creating new user
@JohnMurdoch Do you think plugin can updated in some way that can make it easier for you.
put fields in nimble.fields.enduser.user - these fields are used while creating new user
put fields in nimble.fields.admin.user - this fields are used for updating, that means only these fields will be able to be updated.
Well, to me it seems that there would need need to be two sets of fields - those for all users, and those only for admins, where if you add the fields to the relevant configuration properties then they would appear both in create user and edit user screens.
Also probably provide override functionality for editing complex fields (e.g., dropdowns) even if simple ones (with String or Integer values) are working out of the box just from being added to the configuration.
Apologies if I've misunderstood your question.
Ideally the Nimble user documentation would include a description of the steps needed to:
a) Add a String property to every user, both in edit and create screens
b) Add a reference to another entity (e.g., Company the user works for, assuming each user works for one Company and each Company employs many users), as a drop-down, in both edit and create screens (assume creation/etc. of Company entity happens in other non-Nimble admin screens)
I think both are very common use cases for using Nimble.
P.S. Also which of the fields added belong in User and which in Profile? Perhaps I wasn't reading carefully enough, but I don't think this is explained by Nimble documentation, or even why we need both. That's a different, though related, topic.
Hi to all,
@JohnMurdoch The nimble UserBase class contains all authentication and authorization related information like username, realm, the encrypted password-hash, password history, assigned roles and groups and booleans about account state. It is required to store and verify the user's account information for the underlying Apache Shiro Security Framework. The ProfileBase instead holds the basic application user data like Full Name, Nickname, Email and creationDate. The purpose is to keep the user's authentication profile separated from the user's application profile I guess.