Hello,
I have read all the relevant documentation about this subject but un fortunately I still have some unclear aspects on how to set user privileges to our back office users, for this reason I'd be grateful if someone could give me help for a possible "in depth" explanation about how they work exactly?
Just some questions I may ask are...
1) Which is the difference between the settings I can set using EDIT on the top right side of the Metadata Filed Editor screen chosing "Default schema" and the same ones chosing "User schema" from the dropdown list at the top right side of the Metadata Filed Editor?
2) Which are the differences between the two sections "Deafult schema" and "user Schema" and what do they control?
3) Once I edit a filed setting at the bottom there's a section "Privileges", how do the settings here affect the field or the whole system?
4) Is there a dependency between the authoring and editing privileges wherever they are set?
Besides... what would be the best practice in our case (as it regards user privileges settings)? Our instance of CWIS forsee basically 3 types of users:
- the general public who can just view the content of the resource records (not all of the fileds but just some of them)
- The resource administrators who are in charge to both add a new resource and manage them completely filling the content of the fields
- System administrators who are in caharge of managing the whole system (nothing excluded).
Thank you in advance for any help you could give.
Fabrizio
I beleive the in-depth explanation you're looking for can be located under Help / Collection Administraion Help / Permissions and Access Control.
Regarding your questions, 1 and 2 appear to be the same question -- a "schema" is a set of fields for a particular type of data. The "default" schema is the one that applies to resources. The "user" schema is the one that applies to users. The remainder of your questions appear to apply to the "default" schema.
Regarding question 3, I beleive the "How Permissions are Applied" section of Permissions and Access Control answers this question. It says: This system works in two levels: Schema permissions and field permissions. The schema permissions establish minimum requirements that apply to all fields. Field permissions can be used to provide additional restrictions for specific fields beyond what the schema requires. Note that for each field, CWIS first evaluates the schema permissions and only if those requirements are satisfied does it proceed to check the field permissions.
Regarding question 4, the introduction to Permissions and Access control answers this question. It says: In CWIS, 'Authoring' refers to the creation of new resources, 'Editing' refers to the modification of existing resources, and 'Viewing' refers to the display of resources.
The use case you describe is very close to the one for which the CWIS default permissions were designed. It shouldn't actually be necessary to change the default schema permissions at all.
On any fields that you don't want to be viewable to the public, you would set the additional requirements to:
Current user has Master Resource Administrator privilege
Whenever a resource record is displayed, the corresponding schema permissions (in this case from the default schema) are evaluated for each field. For fields that should not be viewable to the public (Release flag is false), the schema permissions will deny access. For other fields, the permissions on individual fields will then be checked. The above requirement causes a field to be viewable only to users with Master Resource Administrator privilege.
In your example, it seems like no fields would be excluded from either resource administrators or system administrators. So the simplest thing there would be to assign the "Master Resource Administrator" privilege to both sets of users (using "Edit Users").
Hopefully this addresses your questions, but please let me know if any remain unanswered.
Hello,
I think to have understood but I have a practical example to submit you that puts into discussion my comprehension of the privilege mechanisms.
Actually I have a fresh installation of CWIS release 3.9.0.
As a fresh installation it has no resources (I have purged all the sample ones) and just two users: an administrator called "guidicini" and a user called "ppallino" who is assigned a privilege of "Master Resource Administrator".
In the database there is only one resource which was fully created by the administrator ("guidicini").
Afer having created the only resource actually present as an administrator I just added one more field leaving to it the permissions you can see in "screenshot 1".
According to these permissions (given i haven't misundersood anything) a user with the privilege "Master Resource Administrator" is expcted to be able to edit that field.
But, if i log in as user "ppallino" who is assigned "Master REsource Administrator"privilege only (see screenshot 2) when I try to edit the resource fields I can edit all the fileds BUT the one added.
Should you need further screenshot to understand how everything is configured i am happy to provide them. I defintely need to understand well where i am making mistakes.
Thank you in advance!!
When you created your new field, did you mark it Editable (should be on the 5th line of EditMetadataField)?
Yes. I attach the screenshot of the screen you mentioned relative to the field in question.
As far as I can tell from what you've provided, that field should indeed be editable. This may be a bug in 3.9.0. I have tried to replicate your situation in our test environment, but so far I have not been able to.
Can you compare all the settings of your new field with all the settings of the "Description" field, making note of any differences?
Can you attach a screenshot of the EditResource page, showing this field as not editable?
YEs certainly.
Find attached 3 files:
- Description field settings.pdf
- personal notes field.pdf (whose italian label is "note personali")
- resource editing page for user ppallino.pdf --> this is the resource editing page for user with MAster Resource REcord privilege set. Note that the all the fileds are editable but the "note personali" which is "greyed" out.
Should you need further settings do not hesitate to ask.
Just a note: the same kind of behaviour is shown by version 3.2.0 of CWIS which I have used to upgrade a 2.4.x version at work.
Thank you,
Fabrizio
Thank you, this is very helpful.
Does the "Personal Notes" field work if you disable HTML, similar to how the "Description" field is working? If so, do you have anything in your browser which may be blocking javascript? That may be the problem, as javascript is required for the WYSIWYG editor.
Under Administration / System Configuration / Advanced System Configuration, what are your settings for "Use Minimized Javascript", "Javascript Minimization Enabled", and "Add URL Fingerprinting" ? On the Administration page, are there any "Recent Log Messages" listed that mention a failure to write minimized javascript files?
Hello,
you gave me a helpful hint.
Disabling the WYSIWYG editor in the "Personal notes" field the filed becomes editable.
I was using Chrome as a browser to edit the resource as ppallino user. But a check of the settings of the browser showed me that javascript is enabled and not blocked.
As it regards the settings you asked me about in the last part of your message all the 3 are enabled.
As it regards possible listed "Recent Log messages" there are none actually. Both if i activaate and deactivate the WYSIWYG editor.
Considering the above I think that what seems to fix the problem with this field is the activation or deactivation of the editor.
All this happens on Chrome and Firefox on a MAC with OS X El Capitan 10.11.5
As a webserver I am using MAMP last version.
Does all this mean, in your opinion, that i am not able to use the editor?
Thank you!
Fabrizio
Can you disable "Use Minimized Javascript", "Javascript Minimization Enabled", and "Add URL Fingerprinting" in Advanced System Configuration, and then test if the rich text editor works?
When the Rich Text Editor is enabled for a field, this changes the HTML that is generated on the editing screen, replacing the simple textarea with a more complex set of elements that in turn load the CKEditor javascript library. From the screenshots you have posted, it looks like the JS libraries are not being properly loaded, which prevents the editing interface from appearing.
The three Advanced SysConfig options I mention above affect how the javascript is compressed server-side before delivery to the browser. My guess is that one or more of these options does not currently work in the MAMP environment. If you disable all of them, you can probably still use the rich text editor. If we can replicate this bug in our own MAMP setup, we will work to have it fixed for the 3.9.1 release.
Done.
Unfortunately this doesn't change anything: the field remains not editable. The only switch that appears to work is the WYSIWYG editor deactivated.
FAb
If you enable the 'web console' in either browser, does it show any errors when loading the page?
Does it report loading
lib/CKEditor/ckeditor.js,interface/default/include/ckeditor_setup.js, andlib/CKEditor/config.js?Hello and apologies for the delay in replying.
I have just checked and the only errors I can see using SAFARI are the ones shown in attached image1
In Chrome quite a similar one which is shown in image2 attached below.
Fabrizio
Ah, I think I see what's happening. CKEditor is attempting to load the Italian user interface, but failing and dying because it then has no user interface. Can you download
it.jsfrom https://github.com/ckeditor/ckeditor-dev/blob/release/4.3.x/lang/lt.js and place it inside yourlib/CKEditor/langdirectory?