I'm probably going about this the wrong way but...
I’ve added a field to the User Profile called profile_real_name which is required by the user. Is there a way to access the details in CCK?
For example in CCK when creating a new field I can access the user’s username with the ‘User reference’ Field type and setting the ‘Widget type’ to ‘Autocomplete text field’. Can I do the same with my real name field?
Many thanks
The problem is that Users are not a part of the node system and therefore fields cannot be mapped to Users using only Core code.
CCK doesn't have a way to manipulate and add fields to profile.
There is one solution to this: nodeprofile (Drupal 5). This module creates a node type for users, so each user effectively has one node that is associated with it. You can then add fields to this new content type and manipulate them how you wish.
There is also a module, content_profile, for Drupal 6 which does the same.
Related
I am new to modx revo and trying to add extra fields in user creation from backend. Which file should i check out for customization. I added the custom field in backend with this code on modx.panel.user.js file.
{
id: 'modx-user-companyname'
,name: 'company_name'
,fieldLabel: _('company_name')
,xtype: 'textfield'
,anchor: '100%'
,maxLength: 255
}
I created custom column named company_name in database table modx_users but I don't know how to save it on database. Any ideas?
Editing the core code of modx is considered a bad idea.
Really you have two options if you want to add extra properties to users...
Firstly you could take advantage of modUser extended field which allows you to store extra properties for the user and are stored as JSON. This is available in the default ui in the manager.
See Understanding MODX Extended User Fields and JSON
Secondly, you could extend modUser. This would give you full control over the user model and could then add additional related entities. From then, you might be able to alter the user form in the manager with form customisation or write a plugin to alter view.
See Extending modUser
Basically what I want to do is create a form whilst within another form and pass values from the earlier form to the second. Complicated I know but here is what I got.
#Do(#Command([Compose];"LPK"); #SetField("PR_Make"; PR_Make))
The fields in both forms have the same name and this code is called when first document is attempted to be saved.
I think instead of editing the field on the second form it just saves a field as itself instead. Any help appreciated.
The best and common way is to enable form property "Formulas inherit values from selected document" in second form "LPK".
Add a default value formula to second form's fields you want to inherit and put just the name of field itself in. For your example default value formula it would be
PR_Make
Make sure you save document first and then create the new document.
Knut Hermann's answwer is the 'standard' way of achieving such things but there are other methods- eg you can use environment variables ..
Something like:
#Environment("PR_Make") := PR_Make;
#Command([Compose];"LPK");
Then set the default value for PR_Make in your new form as ..
#Environment("PR_Make")
FYI Environment variables are written to the user's Notes.ini file and so remain even after Notes has been closed and re-opened. #Environemt doens't work too well with Web applications as it uses the server's notes.ini.
An alternative would be to use profile documents:
#SetProfileField( "PRDefaults"; "PR_Make" ; PR_Make;#Username);
#Command([Compose];"LPK");
.. in the default field for PR_Make on new form :
#GetProfileField( "PRDefaults"; "PR_Make"; #Username);
Profile documents are stored as a kind of hidden document in the Notes database and persist with the database. The last parameter sets a further subdivision by username so each user gets their own profile doc - a bit like a personal profile for "PRDefaults". You can miss this last parameter #Username out, to have one profile doc per database but there's a risk of two people trying to use it at the same time and clashing.
Profile docs also work with web applications.
I have created a custom CCK field and gave proper permission to users, but
for some reason I cannot access the field by using
$node->field_name
does anybody have Idea about this ?
Thanks In advance
-S
print_r($node->field_machine_readable_name) and see what it prints. You can use the devel module to see deep information about various fields and functions.
I found that for some reason, in drupal 6 if we are using same CCK field for different content types, Nodes that had already created may not have the newly created field. When you edit and save the node. you will get the value for the new field.
What I need
I have a custom Entity with that with multiple fields. Admin Role has "god" access. All other roles except for one have read only. The one non admin role with update access, should only be able to update a single field.
What I believe to be true
I believe I have three main options to implement this requirement:
Enable Update Access to the role for that entity then write Javascript to disable all fields on the form for that role, except for the one that I want that role to be able to edit
Enable Update Access to the role for that entity then create a new form that disables all fields on the form for that role, except for the one that I want that role to be able to edit.
Enable Update Access to the role for that entity then turn on field security for each field, disabling access using the field security, for each field except for the one I want them to edit.
What's the Best Practice?
What options should I choose?
If I go with options 1 or 2, will the user be able to edit the field on the bulk edit form?
From a user perspective, I think it's confusing when a form opens up with things enabled, then they get locked down. Plus someone could possibly get data in there before the fields get locked. I'd say you'd have to combine this with a plugin to prevent changing fields you don't want changed.
I like this option better, although again, the field can be unlocked if someone knows what they're doing, so a plugin to double check would be nice.
This would avoid having to double check in a plugin, but you also have to rely on the admin correctly setting up security for new fields going forward. If that's not a concern, this might be best.
Bulk edit is a global privilege, so they'd have bulk edit for all entities. Also, the bulk edit form does not load scripts, so that knocks out option 1. I'd say if it's just this one field, I might leave the privilege locked down and provide my own Bulk edit button on the grid that would show a custom page that just has that one field on it, then handle the updates though script.
2 is most likely best, or as an alternative put the fields in the header or footer rather than as read-only fields on the form.
This also means the fields won't be available to bulk edit, but other methods such as data import or workflows would let users get round this if they know how and have rights to do such things.
3 Field Security is the most robust and works for all scenarios
Possible option 4: create another entity to contain those fields and apply different security to that entity. If created as a child, show the record in a grid on the form with the values included in the view. If it is a parent then you could use methods such as showing the values via an HTML webresource page included on the form.
1.) I had an implementation for user registration for which I needed to make two extra tables and used "users" table as well(I've made a custom module for this purpose). I've collected the information while user is registering and put them in appropriate tables. Now I need to provide user with an interface where he can update his profile(this includes tables which I mentioned above).
2.) Further more, I need to make filters that admin can see the list of users e.g. who have salary more than $10,000. I need to provide two predefined filters and facility to make more filters for admin.
How can I do both of the above question? is there any module?
Thanks for your reply.
1) You could use hook_user "form" operation to add fields to the user account edit form. You could then use the "submit" operation to write any changes to the database.
2) I recommend using the Table Wizard module to expose the data to Views. Then use Views to do the reporting. That would give you the ability to easily add more filters later, as needed.