Pages Permissions

[TDBF]

I have around 20 databases and each one as many custom fields added to them. This wouldn't have been an issue however, today I decided to add another group to have permissions to add and edit content and what a nightmare this is to do.

Is it really necessary to have the permissions on each of the fields, on top of the database permissions as this just seems like overkill to me?

If you won't remove the permissions on the fields, at least give us a way to change them all globally at once rather than individually at a time. This is just so time consuming.

[KentT]

The permissions seem to cascade down on categories and subcategories from the database setting, unless you specifically change them, and there's the selection to set them independently.  You'd think fields should operate the same way.

[opentype]

The key is how you set up this new group. Make sure you copy another group that already has the settings you want. If you don’t do that, you will have to edit the permissions of each field. 

[TDBF]

30 minutes ago, opentype said:

The key is how you set up this new group. Make sure you copy another group that already has the settings you want. If you don’t do that, you will have to edit the permissions of each field. 

I didn't add another group to the members groups.

I setup Pages initially only allow administrators to add and edit articles, and I then wanted to give another group (that was already there) the ability to do this. I should have just been able to go into the database permission and change the Add records and Edit Record for this group and that should have been enough. The Field settings in my opinion are not required and waste calls on the database each time.

I personally would like to see the permission on fields removed or a way to turn them off completely and use the database permissions as a global for the form.

That is my personal opinion, yours may differ and I apologise if that is the case.

[opentype]

An example for the field permission use is the bug tracker here. IPS users can create bug reports, but the status and “fixed in version” can only by set by the staff. There can even be a notes field only the IPS staff can see. If all fields share the same permissions, none of that would be possible. 

[TDBF]

3 minutes ago, opentype said:

An example for the field permission use is the bug tracker here. IPS users can create bug reports, but the status and “fixed in version” can only by set by the staff. There can even be a notes field only the IPS staff can see. If all fields share the same permissions, none of that would be possible. 

That was why I suggested a way of changing all of the field permissions in a global way or the ability for the end user to use permission's on fields or not.

[KentT]

8 minutes ago, TDBF said:

That was why I suggested a way of changing all of the field permissions in a global way or the ability for the end user to use permission's on fields or not.

I'm using categories/subcategories, and control the permissions via category to make them publicly visible (i.e. publish them). The field definitions were set once and seem to flow down just fine.  Then all I have to change is the category permissions to go live.

[TDBF]

9 minutes ago, KentT said:

I'm using categories/subcategories, and control the permissions via category to make them publicly visible (i.e. publish them). The field definitions were set once and seem to flow down just fine.  Then all I have to change is the category permissions to go live.

Which is great until you realise that you need to change a setting for each field in each category for your databases.

A global way to edit all the fields settings in one place would have helped today.

If you have a disability such as RSI or limited hand movement, then you will understand why this needs to be changed.

[KentT]

I'm not refuting your point at all, only passing on my experiences...  It would be nice to do things more globally in many places -- even in the ACP records or categories list -- by doing something like a multiple select, then Edit, and that edit applies to all the items selected.  

There's lots of improvements that could be made in the ACP interface.  Personally I've found the whole drag-and-drop ACP GUI to be very fragile, and problematic -- whether trying to rearrange/resequence menu items or database categories.  It takes multiple attempts to get the item in the exact position you want, or if you have a long list, you move it part way down the page, then scroll, then move it some more.  Oh well, I'm off on a tangent..

[TDBF]

6 minutes ago, KentT said:

I'm not refuting your point at all, only passing on my experiences...  It would be nice to do things more globally in many places -- even in the ACP records or categories list -- by doing something like a multiple select, then Edit, and that edit applies to all the items selected.  

There's lots of improvements that could be made in the ACP interface.  Personally I've found the whole drag-and-drop ACP GUI to be very fragile, and problematic -- whether trying to rearrange/resequence menu items or database categories.  It takes multiple attempts to get the item in the exact position you want, or if you have a long list, you move it part way down the page, then scroll, then move it some more.  Oh well, I'm off on a tangent..

I understand what you mean. the end user shouldn't have to worry about setting things up right from the beginning. The software should allow the end user to change things quickly and without effort, and take into consideration the needs of those who have disabilities and prevent the risk of RSI.

I just wish that that developers had given the same respect to the back-end as they did with the frontend. The ability to delete multiple items at once would go a long way in helping for a start. If I want to clear the logs on our forum, I do this via the database because deleting them one by one is not an option for me.