Needs work
Project:
Flexinode
Version:
master
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
21 Sep 2005 at 21:07 UTC
Updated:
11 May 2006 at 09:24 UTC
Jump to comment: Most recent file
What would be involved in making fields enabled based on role? Perhaps, when adding a field, there could be a drop down selection to limit the field to a certain role. Default would be to allow all roles. In the database table, all fields would be there, but only certain ones would display in the edit form. The node itself would only display those fields that the "owner" is allowed to enter.
So lets imagine that authenticated users are allowed to create a flexinode without adding an MP3 and those of role "member" are allowed to to create the SAME flexinode WITH an MP3. The edit form should ONLY show the MP3 input box for the "member". The authenticated user's node will NOT show an empty label for the MP3.
These could be two different flexinodes - one for member, one for user - but what happens when a user becomes a member or vice versa? When a user becomes a member, they are able to add more information to their node. If a memeber gets knocked down to user, their info is still there somewhere, but it's hidden - until they pay their bill or whatever.
There is also the issue of allowing restricting fields to multiple roles, but that doesn't apply to me at this time. I don't know if that is more complicated or not. Heck, we have to start somewhere.
You may be able to find a sponsor. I won't name any names, but her first initial is jo1ene.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | flexinode_install_add_field_crud_tables.patch.txt | 3.1 KB | Bèr Kessels |
| #1 | flexinode_crud.patch | 9.89 KB | Bèr Kessels |
Comments
Comment #1
Bèr Kessels commentedI am hijacking this old feature request for a project I am working on now.
The first code is attached, but note that this is work in progress, it does not yet work. It shows my ideas and route though.
What we will get is:
* Every field gets per-role permissions for:
* view (may see the values of that field, )
* create (may insert values on creation of a new node)
* edit (may edit the value in a node. No 'view' perm for this, obviously means no edit perm either)
* By default all roles have all permissions.
* Permissions are on top of the default permissions. Someone who cannot edit FlexinodeTypeZ will not be able to edit specific fields, obviously.
* All permissions are transparant and degrading. No need to update old content. If you dont need this, its not in your way, either.
Bèr
Comment #2
marcoBauli commentedDefinitely usefull for many different purposes in users submitted content sites.
I am not a dev, but still i can offer for testing/feedback and everything else that can help to get this to life!
Comment #3
Bèr Kessels commentedHere is a patch that introduces the table structures and stuff into the .install.
Comment #4
oziumjinx commentedgreat idea...im looking for somethign very similar: for users within the proper role (authenticated users) display the download button which goes directly to a file.
for users that are not 'authenticated' display a default "Register Now For Free Access" button which directs to registration form....it seems like your patch would be able to accomplish this...is this patch being developed for 4.7 or just earlier?
-=Vince
Comment #5
Bèr Kessels commented@vince. files are a different story! becuase anyone can access a file directly, hiding the download button is not the same as securing files.