In an OrchardCms site, I need to create a hierarchical menu where I can show and hide menu items by user role. What is the best way to approach this?
One possible way would be to create and manage two menu's, each pertaining to a different layer where the layer rule species the respective Role. However, this means managing two Menu's which is not ideal. Many items in each menu would need to be duplicated.
Another way would be to create a custom Menu Part. The downside here is it seems like overkill.
Or am I on the wrong track completely, should I be looking more at filtering content items by role instead? In this scenario, I believe I would still need a way to specify menu filters.
I think Advanced Menu (available from the gallery) does menu trimming based on permissions.
Update: my bad. Try Quanta instead (part of the Science project). Should work well with Cartography.
I was able to create multiple menus filtered by role in layers with this simple PCG.RoleLayer module. You will still have to make separate menus though, and it doesn't restrict url access unless you change permissions.
After enabling the module, you can create rules for roles. For example,
role("Administrator")
Would make that layer only visible to those with the administrator role.
Related
Within the implementation of MDM based on the PIMCORE solution, we wish to segregate data according to user rights. The goal is to restrict access to the attributes of an object according to predefined roles.
The different possibilities were to go through either perspectives or customer views but it is not possible to add more detailed restrictions at the attribute level. The other possibility would be to do specific development in PIMCORE, but this is still a bit expensive.
In your opinion, is there a native way to manage this data segregation in PIMCORE? Or do you have a way to do this on a specific development?
There are the following possibilities:
Custom layouts
Custom Layouts give you the possibility to define different views on data objects for certain users. You can hide certain fields from the admin backend to certain users which is a great way to achieve what you want. The drawback is that this is not suited for "high-security scenarios" as the full data objects are still sent in the background.
So if the data is highly secure it might be readable within the communication streams (https://pimcore.com/docs/6.x/Development_Documentation/Objects/Object_Classes/Class_Settings/Custom_Layouts.html).
Encrypted fields
Maybe you could use encrypted fields to further improve security. A combination of custom layouts and encrypted fields should at least make data unreadable to certain users (https://pimcore.com/docs/6.x/Development_Documentation/Objects/Object_Classes/Data_Types/Others.html). I am not 100% sure, it should be tested.
Workflows
You could use Workflows in order to restrict certain actions on objects depending on the current object state. Workflows have a possibility to fully implement permissions and dissallow certain actions for certain users.
https://pimcore.com/docs/6.x/Development_Documentation/Workflow_Management/Permissions.html
Use Relations
This is probably one of the simplest and best solutions. Create seperate classes for the sensitive data and connect the data objects via Many-To-One or Many-To-Many relationships and restrict access on them. This way you can ensure that certain users never can access or edit the sensitive data.
https://pimcore.com/docs/6.x/Development_Documentation/Objects/Object_Classes/Data_Types/Relation_Types.html
I want to be able to bring a dataset into an edit/create form because I need the respective resource in order to associate it to the main model.
Say, a store has many employees. I want , from an ui perspective, to be able to add employees to the store.
I am able to to this via a custom component, however I want to know if I am able to use the List component to fetch a certain resource, ,because I have a feeling that I'm not doing this properly now. Adminonrest has the tools to render a paginated list of resources, so how can I make better use of these tools ? Then make a custom iterator to represent the model anyway I want to (maybe even use the datagrid component). I can then attach custom actions.
What would the best pattern for this situation be ? Thanks.
No, this feature is not supported. You can display employees, using the ReferenceManyField but we don't support creating them from the Edit page.
Is it possible to restrict part of a smart to only a certain user group and if the user trying to edit the smart form content is not of that group, then the user cannot change that portion of the content?
Example:
Let's say I have an Employee smart form with fields for EmployeeBio, EmployeeHireDate, and EmployeeDept. Would it be possible to allow the general author user group to be able to edit the EmployeeBio field, but restrict the EmployeeDept and EmployeeHireDate fields to only an HRAdmin user group?
If it helps, I am using Ektron 9.00 SP3.
As far as I know, you either can edit a content block or you can't; there isn't a way to subdivide permissions on a per-smartform-field basis.
What you can do, is group the "restricted" fields into their own smartform, and then reference that via a content resource selector field.
So your Employee smart form might look like this:
/root/txtName (not in your example, I know...)
/root/rtfBio
/root/cresHRID
Side note: I'm using hungarian notation on my field names here. txt indicates a plain text field, rtf indicates a rich text (html) field, and cres indicates a content resource selector.
Then you could have a second smart form... let's call it "EmployeeHR", and it would have the following structure:
/root/hireDate
/root/txtDepartment
That would, in theory, work. However, I must say that I really don't like splitting up this particular type of data in this way. First, department feels like it would function better as a taxonomy to which you could add the content block. Second, it feels like this type of data would be better served by housing it outside of ektron and then using a DxH (Digital Experience Hub) connector to bring the data into Ektron. This way the external system could handle permissions at a more granular level, and you would still have access to the data within Ektron for use elsewhere within the site.
UPDATE
As I ponder this question some more, another option comes to mind. You could write an ASPX page or UserControl that checks to make sure you're logged in and a member of a particular group before presenting you with a custom edit screen. The following code will check if the current user is a member of the admin group; you can swap out a different group id to fit your needs:
// Not sure off hand which of these using statements provides access to EkConstants...
using Ektron.Cms;
using Ektron.Cms.Common;
using Ektron.Cms.Content;
var userGroupApi = new Ektron.Cms.Framework.User.UserGroupManager();
var isInGroup = userGroupApi.IsUserInGroup(currentUserId, EkConstants.g_AdminGroup);
This could be implemented as an ASPX page on your site, or it could be implemented as a widget and placed on the user's Smart Desktop tab of the workarea. Either way, you have a lot of options for getting what you want, just nothing "out of the box".
I need to set up different permission on an object based on its workflow state. For instance, 'manager group' can edit the object only if state=draft but 'super manager group' can edit it also if state=validated.
It seems that's not possible using ir.model.access and I'm evaluating if it could be done using ir.rule. It seems not...
Is there a official way to get this or do I need to implement this feature (maybe by adding a condition into ir.model.access machinery).
This is not possible by default with ir.model.access, because this permission model is designed to act like simple Unix permission on CRUD operations, and it is statically defined, per-model and per-group.
You may be able to implement something like this using ir.rule, as it implements dynamic per-record access control based on field values. By having a set of rules defined only on the write and unlink operations and based on the state field, you will be able to prevent some groups from modifying records in certain states. By using the technique of an always-true rule [(1,'=',1)] you can then relax a non-global rule for users who have a "super-access" group. See also this answer.
This option will have important caveats however:
Be careful not to make those rules apply for read, as it will make the records completely disappear, and generally wreak havoc in your processes
The interface will not become read-only when the rule is in effect, and if you want to make the fields and buttons read-only you will have to find a way to specify this via attrs in a manner that depends on the user's groups. See also this Launchpad question.
the Save button in the UI will not be disabled
The standard error reporting in case of ir.rule restriction is not very clear, so it will certainly confuse users (note: it's being improved for 7.0)
As you see, using ir.rule filters for this purpose is far from a perfect solution, and you will first need to find appropriate solutions for the above issues.
Ultimately, you might have an easier task of implementing your own logic for this, plugging a new mechanism in the ORM primitive API methods: fields_view_get (for making fields dynamically read-only based on the user groups) and the CRUD methods (for actually restricting the operations)
There is another way instead of hacking web-client.
You can always have 2 views for the same Object .
For manager group.
For super manager group.
In manager group you can use attrs = {'readonly': [('state', '!=', 'draft')]}
or any condition as you needed.
And in the same way in super manager group, you can put his condition for fields.
I have this feature working on a production environment, using just Record Rules: in Project Issues, "basic users" can create and cancel issues, but can't open or close them.
Despite the GUI limitations mentioned by #odony, it works perfectly.
These are the Record Rules used::
There is a special case that needs attention: changing from a read-write State to a read-only State:
In the action's method, if the the State is changed after other write operations, the user will be able to change the State; but if there are some write operations after the State update, the user will not be able to change State.
In my example, the Project Issue method to Open an issue is case_open(). It first changes State and then does additional changes, like settting Open Date, User and Message history. Because of this, basic users can't Open issues. If you want them to be able to do so, case_open() must be overridden so that it changes State after all other write operations are done.
I got a similar requirement...
My requirement was to make a char field(say "test_123") readonly in the sale.order if the user comes under the group "sale user" otherwise editable for the group "Sale Manager".
That is, if the sale order is in draft state then anyone can edit, but it the sale order is confirmed then this field "test_123" is only editable for "Sale Manger"
What I did is I added a functional field (is_group_manager) which returns True if the user comes under the group "sale manager" and the state is not "draft" otherwise false.
Then in the xml view I added the field "test_123" with attribute attrs="{'readonly':[('is_group_manager','=',0)]}"
for example
<field name="is_group_manager" invisible="1"/>
<field name="test_123" attrs="{'readonly':[('is_group_manager','=',0)]}"/>
This will work only in openerp v6.0. Maybe this will be helpful for you. :)
I'm implementing a document management site on SharePoint 2010. Each document that is stored on the site, is tagged with one or more geographical locations indicating what the content of the document is about. I have implemented this using a Managed Metadata field that is bound to a term set in the term store containing all possible locations. The locations are organized hierarchically, so let’s say first by country, then by region, city etc.
I want to be able to quickly locate documents in a document library for a given location. SharePoint 2010 offers 3 out-of-the-box ways to accomplish this: (1) filtering on the column header, (2) using metadata navigation, and (3) using key filters.
So far, so good. Now this is where things are getting tricky. Each location in the term store is identified by a number of different labels. So each location has a default label and an average of 3 or 4 additional labels (synonyms). For example: a location could be referred to as “Amsterdam”, “S-123” and “W-456”.
I want to be able to:
Filter the document library by using any of the labels including the
synonyms
Include all locations that are below the location that he/she
specifies, in short: to recursively set the filter
Going back to the 3 out-of-the-box options:
Filtering on the column header; does NOT support use of synonyms and
does NOT support recursive filtering
Using metadata navigation; does NOT support use of synonyms but does
support recursive filtering
Using key filters; does support use of synonyms but does NOT support
recursive filtering
Can you think of a creative solution that meets my requirements using the out-of-the-box controls? And if not, what options do I have for full customization (custom filter web part, extending out-of-the-box web parts etc.)?
Hope to hear from you!
Regards,
Erik
I think I might have an answer. This works in our System - SharePoint 2010.
In you SharePoint instance, create your View of the list, but don't define any Filters. Save the View.
Open SharePoint Designer 2010 and navigate to the list and view.
In Design view, you then need to select the "WebPartPages:XsltListViewWebPart" (you may need to click one on the column headings to get the grey page elements to appear).
At the top of the screen, select the Options Ribbon tab, a green List View Tools upper-tab appears.
On this ribbon, far left, select Filter.
Define you filters.
It is tricky and not a smooth UI. Note the Group button allowing you to create groups of AND and OR elements. (I'd post an image here of the UI, but I no not have the experience points yet.)
Good Luck.