Moodle

Fields of database instancees with restricted aceess

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.9.3
  • Fix Version/s: None
  • Labels:
    None
  • Affected Branches:
    MOODLE_19_STABLE

Description

As described in http://moodle.org/mod/forum/discuss.php?d=110362
I post here the same request.

I built a database with 10 fields.
Eight of them are for remote users, they are supposed to fill them.

Two of them need to be filled ONLY by the course teachers.
Is there a way to restrict the access to these two "special" fields?

What I am asking is a database field level view/read/write permission to assign only to specific roles.

The same feature should be implemented by managing more than one form to add records to the database.
If I had two different input forms, I would assign one form to teachers and one to students by role.
This would be great.

  1. data_mod.patch
    16/Dec/08 3:22 AM
    23 kB
    Daniele Cordella
  2. data_modrev02.patch
    16/Dec/08 10:58 PM
    25 kB
    Daniele Cordella

Issue Links

Activity

Hide
Martin Dougiamas added a comment -

I agree that being allowed to assign permissions/overrides to specific fields would be a great thing and would probably enable a lot of simple workflow scenarios. +1

Show
Martin Dougiamas added a comment - I agree that being allowed to assign permissions/overrides to specific fields would be a great thing and would probably enable a lot of simple workflow scenarios. +1
Hide
Andrea Bicciolo added a comment -

I really think this feature could open many scenarios. For example, a document repository with different level of access. +1 for the feature.

Show
Andrea Bicciolo added a comment - I really think this feature could open many scenarios. For example, a document repository with different level of access. +1 for the feature.
Hide
Daniele Cordella added a comment -

Let me write down a project I am tryng to draw in my brain in order to get this new feature.
What I feel best is: provide a permission for each course-creator-defined field and assign it to users.
In this general view, the teacher can assign each even (2nd, 4th, 6th..) field to students of the group 1, only the first 5 fields to students with a name starting with "A", all the fields to teachers, and so forth... and the database will be different in very many ways for each different user/group.
Really very nice but not feasible with my low low low low competence.

A second and less nice solution (but really very simple to implement) consist in:
-> add a flag to each course-creator-defined field. Let me call this flag: restrictview
-> add a new permission: seerestrictview
and it's a cinch.
User/groups with the capability: seerestrictview will see all fields, other no!!!

What do you think about?
Do you have any suggestion?
From your view point... is really not drivable the first road?

Show
Daniele Cordella added a comment - Let me write down a project I am tryng to draw in my brain in order to get this new feature. What I feel best is: provide a permission for each course-creator-defined field and assign it to users. In this general view, the teacher can assign each even (2nd, 4th, 6th..) field to students of the group 1, only the first 5 fields to students with a name starting with "A", all the fields to teachers, and so forth... and the database will be different in very many ways for each different user/group. Really very nice but not feasible with my low low low low competence. A second and less nice solution (but really very simple to implement) consist in: -> add a flag to each course-creator-defined field. Let me call this flag: restrictview -> add a new permission: seerestrictview and it's a cinch. User/groups with the capability: seerestrictview will see all fields, other no!!! What do you think about? Do you have any suggestion? From your view point... is really not drivable the first road?
Hide
Daniele Cordella added a comment -

This is the first dratf I wrote today.
What I planned with the friend Abix, is what follow:
--> 1. each user defined field has two more flags. They are using the available pre-buil param9 and param10 left unused by Martin (I believe). I called them "restrictview" and "restrictedit".
--> 2. I defined two more capabilities. They are "seerestricted" and "editrestricted". Their default is CAP_ALLOW for admin, editingteacher, teacher.
--> On the basis of the two new flags and of the permissions each user can: see and edit, see only, don't see (and, of course don't edit) each field.

As far As I understand, this list of possibilities has to be applyed to each of the four forms: View list, View single, Search, Add entry.

What does this mean?
For instance, if in the Search form I have a field with the flag9 = 1 (restrictview) this means that, teacher can search for that field but the student can't. The ame is true for all the other forms.

I added this new feature ONLY to the Add entry/Modify form.
What I did and what is still to do is reported in the next table.

View list View single Search Add entry

-----------------------------------------------------------------------
see | missing | missing | missing | done |
-----------------------------------------------------------------------
edit | missing | missing | missing | done |
-----------------------------------------------------------------------

Before continuing I would like a feedback from you.
What do you think about? Am I wasting my time? Am I in the right direction?
There is something bettter to know or to plan before?
Please, leave me a feedback. Thank you in advance.

My patch is attached, of course.

Show
Daniele Cordella added a comment - This is the first dratf I wrote today. What I planned with the friend Abix, is what follow: --> 1. each user defined field has two more flags. They are using the available pre-buil param9 and param10 left unused by Martin (I believe). I called them "restrictview" and "restrictedit". --> 2. I defined two more capabilities. They are "seerestricted" and "editrestricted". Their default is CAP_ALLOW for admin, editingteacher, teacher. --> On the basis of the two new flags and of the permissions each user can: see and edit, see only, don't see (and, of course don't edit) each field. As far As I understand, this list of possibilities has to be applyed to each of the four forms: View list, View single, Search, Add entry. What does this mean? For instance, if in the Search form I have a field with the flag9 = 1 (restrictview) this means that, teacher can search for that field but the student can't. The ame is true for all the other forms. I added this new feature ONLY to the Add entry/Modify form. What I did and what is still to do is reported in the next table.
View list View single Search Add entry
----------------------------------------------------------------------- see | missing | missing | missing | done | ----------------------------------------------------------------------- edit | missing | missing | missing | done | ----------------------------------------------------------------------- Before continuing I would like a feedback from you. What do you think about? Am I wasting my time? Am I in the right direction? There is something bettter to know or to plan before? Please, leave me a feedback. Thank you in advance. My patch is attached, of course.
Hide
Daniele Cordella added a comment -

Just a few errors less.
Nothing added about what was missing yesterday.

Show
Daniele Cordella added a comment - Just a few errors less. Nothing added about what was missing yesterday.
Hide
Andrea Bicciolo added a comment -

Hello Eloy, rising this improvement to you for your considerations.
Andrea

Show
Andrea Bicciolo added a comment - Hello Eloy, rising this improvement to you for your considerations. Andrea
Hide
Eloy Lafuente (stronk7) added a comment -

Hi,

I think the idea about "restrictedview" and "restrictededit" is cool. And Daniele's patch above seems to have sense, being ok for a site customisation.

Anyway, for Moodle upstream... I think we should implement this in another way, mainly implementing such options as part of the field definition (instead of using param9, param10). There is one bug somewhere about to add some more things to fields like "defaults" and so on. All them should be proper columns in the data_fields table, because they are shared by all field types. paramX fields are for custom params IMO.

Sadly, this implies a DB change and should be considered for being introduced in Moodle 2.0 IMO. But Daniele patch should be good enough for a customised site (though could have some problems upgrading later and so on).

Ciao

Show
Eloy Lafuente (stronk7) added a comment - Hi, I think the idea about "restrictedview" and "restrictededit" is cool. And Daniele's patch above seems to have sense, being ok for a site customisation. Anyway, for Moodle upstream... I think we should implement this in another way, mainly implementing such options as part of the field definition (instead of using param9, param10). There is one bug somewhere about to add some more things to fields like "defaults" and so on. All them should be proper columns in the data_fields table, because they are shared by all field types. paramX fields are for custom params IMO. Sadly, this implies a DB change and should be considered for being introduced in Moodle 2.0 IMO. But Daniele patch should be good enough for a customised site (though could have some problems upgrading later and so on). Ciao
Hide
Mark Drechsler added a comment -

This would be great for developing Personal Development Plan templates - the student has one area of the form they can edit, and the teacher adds their thoughts and opinions (and ratings in drop down fields or something) into the 'restricted' area. Can then be used to print out single pages, or export the data for reporting.

Credit for this idea goes to Mark Bailye btw

Show
Mark Drechsler added a comment - This would be great for developing Personal Development Plan templates - the student has one area of the form they can edit, and the teacher adds their thoughts and opinions (and ratings in drop down fields or something) into the 'restricted' area. Can then be used to print out single pages, or export the data for reporting. Credit for this idea goes to Mark Bailye btw

Dates

  • Created:
    Updated: