Add Contained Stereotypes Bag Part Settings to allow a user to include content types by stereotype, add Displayed Stereotypes property to Content Picker Field Settings, demo about extending the user permissions, and many more waiting for you in our current post!
Orchard Core updates
Add Contained Stereotypes Bag Part Settings to allow a user to include content types by stereotype
When attaching Bag Part to a content type, the user must explicitly set Contained Content Types with an array of content types to be included in the Bag Part. This is good for most cases; however, it would be great to allow for setting the contained content types using Stereotype. The stereotype would be in addition to not in place of Contained Content Types.
For example, we want to group all Contact Methods (phone number, address, email address, etc.) by a stereotype type called ContactMethod. All of these content types share a similar functionality which is a way to contact a person. Now we created a Person content type and attached a Bag Part to it. In this case, we had to explicitly specify each content type in the Contained Content Types. But if a new content type was added later from other feature/module, the user would have manually to edit the Bag Part settings every time/everywhere ContactMethods are used to add the new content type which isn't efficient.
So now the Bag Part is more flexible. And as you can see here, now we have two radio buttons under the Contained Content Types option where the user can select Content Types or Stereotype.
Add Displayed Stereotypes property to Content Picker Field Settings
And this one is quite the same as the previous feature but for the Content Picker Field. For example, we want to group all to-do items (appointments, meetings) by a stereotype type called ToDoTask. All of these content types share similar functionality which is a to-do task. Now we want to use Content Picker Field in a different content type to allow the user to select a to-do-task of any kind. In this case, we have to explicitly specify each content type in the DisplayedContentTypes. But if a new content type was added later from another feature/module, the user would have to manually edit the Content Picker Field settings all time. Everywhere to-do tasks are used to add the new content type which isn't efficient.
So, let's say we navigate to the editor of a Content Picker Field. And here you can say that you can select the Contained Content Types to:
- Display All Content Types
- Content Types
Add settings to form widgets
There was a bug in OC. The option editor wasn't loaded when trying to add Select Input while creating a form. Also, the edit button did not open the modal that would allow you to populate the options using JSON. If the content is saved, and the page is loaded again then the modal and the options editor work just fine.
Another form-related improvement is validation. When creating a form using the Form input widgets like (Input, Select, and Text Area) there is no easy way to add a label and validation elements to the input. The current approach is to add a label widget and then a validation widget which is not always ideal.
We can make this process much simpler by adding settings to the Input, Select, and Text Area widgets with the following properties:
- LabelOption an enum value with the following values (None, Standard, ScreenReaders). By default, None is selected to keep it backward compatible.
- ValidationOptions an enum value with the following values (None, Standard). By default, None is selected to keep it backward compatible.
Now, if the user selects an option other than None in the settings, we’ll create the label in the same widget block. The same applies to ValidationOptions. This will make things like dragging/dropping widgets during edit and controlling the size much easier. At the same time, we output less HTML code. And if we add the validation rules, we’ll have more validation logic which makes the widgets more useful.
And now, the editor of the Select Input looks like the following with the additional options. And of course, the same applies to all of the built-in form inputs.
Extend user permissions
A couple of months back there was a need reported to have some roles to be able to edit a user and some not. And there is a conclusion that the user interface is not very flexible at the moment with the permissions. So, it kind of makes it hard if you have a unique case where you need some specific users to be able to do stuff. And also, to set up who can see what users, when you are listing the users. To be able to test out this feature with us, you have to check out this PR on GitHub.
The first thing that you will notice is the new permissions regarding Users. In this case, we navigated to Security -> Roles and edited the Moderator role.
There are new permissions, for example, Assign any role, Delete any user or Delete users in role - Administrator, List all users, etc. So, you can say you can list all the users, but it doesn't mean you will be able to edit all the users.
If you try to edit a given user, you will notice something new here. As you can see, the user name of the user is not editable, but you can edit the email address of the given user.
This is controlled by settings that you can reach under Configuration -> Settings -> User Profile Settings. As you can see, here you can allow or deny changing the user names or email addresses of the users.
But now back to the users' list. Let's say we have some predefined users and made some changes regarding the permissions of the Moderator role. Now, we logged in with a user who has the Moderator role. After that, the user with the Moderator role will see something like this. First of all, you can notice that there is a little badge under every user that shows the roles the user has. You can also see that this user has permission to see users in the Editor role, but they can't edit or delete the editor user.
Now let's edit the author user! Here you can see that this user can edit the settings of this user but can't fully manage the roles of the author user. They have the option to add or remove the Author role but that's it, nothing more.
And we are just showing you some simple scenarios about what you can achieve and how you can customize the user permissions. If you want to see more complex scenarios, head to YouTube for a recording!
News from the community
Helping Global Health build an Advanced Form Builder using Form.io
When Global Health from Australia approached us with the request to build an advanced form builder using Form.io, it promised to be an interesting project. They were looking to integrate this new form builder deeply into MasterCare+, their Multi-Tenanted SaaS-based platform for Health Care which is built on Orchard CMS. It would allow creating custom forms for a wide range of scenarios in the health care domain, using the advanced editing capabilities of Form.io. The solution built by Lombiq was an important step in bridging the gap between paper forms and electronic health care management. Check out the full post here!
Orchard Dojo Newsletter
Lombiq's Orchard Dojo Newsletter has 354 subscribers! We have started this newsletter to inform the community around Orchard of the latest news about the platform. By subscribing to this newsletter, you will get an e-mail whenever a new post is published to Orchard Dojo, including This week in Orchard of course.
Do you know of other Orchard enthusiasts who you think would like to read our weekly articles? Tell them to subscribe here!