Different Editor Pages for Different Users

Hi Tim,

Good catch! You can make this work by using the "HTML" Separator Type and adding a "name" attribute to an element within the <TR>. For example:

<tr>
<td colspan="2">
<div class="content-box content-box-divider" name="__separator001__">
<div class="content-box-header"><h3>My Separator Text</h3></div>
</div>
</td>
</tr>

I hope this helps!

That does the job! Thanks Chris

For a future release, would it be possible to add the option to hide an editor on the menu bar to a Single Record editor as there is for MultiRecord editors? Or the ability to restrict a field only to Admin users as opposed to both Editor and Admin users? It would be nice to have this flexibility without needing to add some custom programming. Thanks!

Hi,

If I understand the requirements correctly, you could set a Single Record editor to not be visible in the left navigation by unchecking the Access box for that editor under each user account. This would be on a per user basis and setting.

Or....

You could add menuHidden = 1 to the Single Record schema file directly.

This currently isn't a feature to hide Single Records as there isn't UI to allow the record to be hidden and unhidden by checkbox but you could set this directly in the file.

Download the the single record schema from the /data/schema/ folder and edit it menuHidden = 1 like this:
menuType = "single"
menuHidden = 1

Hope that helps!

Thanks Damon. In this case the client will have access to the user account manager, but we wanted to hide one of the editors in order to protect them from themselves. :-)

I'd still find the ability to restrict a field to Admin only more useful than Admin and Editor only, but the second option is a good workaround. Thanks for the tip!

Hi Chris,

I’m stuck again.

I’m trying to use your “showHideFieldsForUsers” plugin (my code is below) to implement a multi level membership scheme and I’ve come up against a bit of a snag.

Here’s the issue:

UPGRADE WORKS FINE
A member upgrades their membership level, and thanks to your plugin they are allowed to access additional fields in the database and they get added functionality.

They create some records with this additional functionality and all records that they have authored appear with all of the information fields available for them to modify.

PROBLEM ON DOWNGRADE
The problem comes in if that member decides to downgrade their membership and they lose access to those additional fields, even for records that already have data in those fields.

QUESTION
Can you think of a way to allow the now downgraded member to access (and modify) the now hidden fields in their records where fields already have data entered in them? Just not to be able to create any new records using those fields?

ALTERNATIVE
I guess that the alternative is that they’d have to delete the existing record and when recreating it, they just won’t be able to enter data into the now hidden fields.

THIS CREATES A DIFFERENT PROBLEM
Since they can’t see the data in the hidden fields, they won’t have any easy way to know when the record needs to be deleted and updated.

Thanks,

Jerry Kornbluth

<?php


// CAVEATS:
// - it is not currently possible to hide Separator fields.

// UPDATE THESE VALUES

$GLOBALS['BETA_USER_SKILL_FIELDS_SKILL_FIELD_NAME'] = 'allowedFolders';

// For each section, copy this block
$GLOBALS['BETA_USER_SKILL_FIELDS_CONFIG']['master_subscription_pages'] = array(

// user's skill values and lists of fields to hide
'entry_level' => array('__separator001__','__separator002__','paypal_payment_address', 'paypal_invoice_description', 'price_of_work','tm_offer_description','short_code','key_word'),
'silver' => array('__separator002__','tm_offer_description','short_code', 'key_word'),
'gold' => array('__separator002__','tm_offer_description','short_code', 'key_word'),
'platinum' => array()

);

// DON'T UPDATE ANYTHING BELOW THIS LINE

// register hooks
addFilter('edit_buttonsRight', 'beta_user_skill_fields_edit_filter', null, 3);

// add javascript to edit pages
function beta_user_skill_fields_edit_filter($html, $tablename, $record) {
global $CURRENT_USER;
$hiddenFields = @$GLOBALS['BETA_USER_SKILL_FIELDS_CONFIG'][$tablename][@$CURRENT_USER[$GLOBALS['BETA_USER_SKILL_FIELDS_SKILL_FIELD_NAME']]];
if (!$hiddenFields) { return $html; }

?>
<script>
$(function(){
<?php foreach($hiddenFields as $hiddenField): ?>
$('*[name="<?php echo $hiddenField; ?>"]').closest('TR').hide();
$('*[name^="<?php echo $hiddenField; ?>:"]').closest('TR').hide();
$('#<?php echo $hiddenField; ?>_iframe').closest('TR').hide();
<?php endforeach; ?>
});
</script>
<?php

return $html;
}

?>

Hi gkornbluth,

I can think of two alternate solutions which might work for you:

1. When downgrading a user, also blank out premium fields for all their records in the database.

2. Write all your front-end code to check if the record's owner is still a premium member before displaying/using any of the premium fields. (This wouldn't work with certain special fields such as hidden, publishDate, etc.)

It would be possible to have the javascript that hides the fields check to see if anything was already entered in them, but that would probably require some complicated code.

As always, our consulting service could build any of these solutions for you. Please let me know if you'd like to proceed that way.

I hope this helps!

Hi Chris,

I think we've solved the issues above for now.

One other question.

Would it be feasible to grey out fields that were not accessible instead of hiding them as with the current plugin?
Thanks,

Jerry