I have checked the samples and read the documentation but did not get an idea on how we can customize or extend the default user management with our custom fields and some custom buttons in there to extend the default behavior.
Cofoundry does not currently support extensions to the user table, the feature is tracked by issue #176.
Related
Is it still possible to push a custom dimension on page view using GTM as pictured here? I set up custom dimensions in GA but do not see the options for adding custom dimensions under More Settings for Page View in Tag Manager. If it possible what steps do you have to complete to enable it?
I don't have an option for this, and the image says "Track Type" which seems to be from an older version of the GUI.
You need to tick the checkbox before "Enable override settings in this tag" (that, or set your custom dimension via the settings variable - but then they might be also used on events).
In 2sxc for DNN, is it possible to set visibility or edit permissions by the field rather than the entity type or template? I'm imagining a case where I want a public form where the submitter can add "Issue" and "Description", but then a staff member can see those fields as well as "Status" - or something like that.
Is this possible?
Thanks.
This is not by itself configurable, but it can be done in a different way.
Usually the public side would be a custom form using jQuery or angular, and it would be optimized to that use case, with much more customized look & feel. Then save using the normal REST API or a custom WebApi.
The backend user can then either have a custom form (more work but more perfect) or just use the standard, which shows him/her all fields.
On my company's Drupal 7 site, I created a field for one of our content types through the admin UI. We decided to hide it from the user until some styling changes make it through to production. Is there a was to programmatically unhide the field via an update hook? I know get at least some of the field information through the field_info_field function, but I'm not sure how if it contains the setting needed to make the field visible to the user. Any help on this would be appreciated.
I know I can unhide it through the UI once the changes hit production, but it would be nice to have an automated way of doing this.
You can hide it programmatically from it's node template with hide() function:
https://api.drupal.org/api/drupal/includes%21common.inc/function/hide/7.x
You can do that conditionally, i.e. by checking user role first.
Now, I'm not sure will this work from update hook, and I'm not even sure why you want to use that hook?!? If users are allowed to edit that content type and you actually want to hide it from edit form then check out my answer here:
Drupal 7 - Hide certain form fields of a content edit form depending on the content data
You can use https://www.drupal.org/project/field_permissions drupal module to hide and unhide fields to users of specific role.Initially during development the field can be made visible to admin role and then later on the permission can be granted to users of other roles
I'm looking for a way to alter the behaviour of comments for a custom post type.
Comments for other post types should be allowed without user login – and that's how it's been set up on the admin panel Discussion settings. However for one particular custom post type I want to enforce that users must be logged in to comment on that post type.
I'm guessing that the way to do this is to alter the discussion settings dynamically before calling custom_form() but I can't find any documentation on how to do that.
The other option would be a way to set this setting in the admin panel but only for this custom post-type.
Is either of these things possible?
update_option('comment_registration',true);
custom_form()
Does the CCK api allow me to create a node type, from a custom module, with a bunch of fields that use CCK to store their state? If so can these fields be locked so that users may not alter them, but still allow the user to add more fields to the node type?
Thanks
I think the answer to your first question is "yes" (for Drupal 6, at least, which has elements of the CCK integrated into Drupal Core). I believe the Amazon module does this sort of thing, albeit it with just one field.
I don't think the idea in your second request is achievable, though. This would seem to require field-level permissions' control whilst Drupal only supports module-level permissions' control.
You could add validation code in the GUI which restricts CCK fields being interfered with on your content type. This would not prevent another module getting in there with an axe, though.
You could add checks which restore your preferred CCK settings whenever they detect some unwanted changes.