Yes, that's correct. You can either copy this code to the replaced PortalCasePage and remove items that should not be present in the page actions (don't declare them) or you can call parent method and then remove items from the items array returned in the collection of the actionMenuItems object.
I am trying to create a process that can add a selection of contacts to a participants detail by picking select all and then clicking on the action in the actions drop down. I've gotten the process to start but it only grabs 30 records at once.
I know that this is due to Creatio only loading so many records at once as a way to not stress the system too much. However, I need a way to collect more than 30 records. I'm trying to figure out a way to get Creatio to load the records once I've triggered the process.
It's fine if there's a delay while Creatio loads the records, I can always put up a message about how it may take some time. I just need to get the records.
Currently, if a process is started, it will run from all actions that do not have a previous step. This means that troubleshooting a complex process requires inserting false branches if a step is to be skipped for testing, rather that just deleting undesired paths. Processes should only start from a Start event. If a step does not have a Start event leading into it, it should be ignored.
That makes sense from the perspective of reading a process flow and process flow notation. It doesn't make sense from a software development perspective. There are many features in programming process flows in bpm'online that are not strictly about BPMN, but rather are about managing data and control of software. I believe this is a case where not requiring a preceding Start event to run a branch doesn't make sense from the perspective of software usability and reliability.
Currently the access rights changes are separated into remove and add. Selecting access rights changes is confusing because the checkboxes do the opposite things in the sections. It would be much simpler and intuitive to have one list of User(s)/Role(s) and use the check boxes to indicate what the state they should be in regarding reading, editing and deleting when the process step is completed. The question displayed could be, "Which access rights to assign?" This could instead be implemented in a new System action, "Assign access rights," to avoid potentially impacting existing processes that use Change access rights.
Well, changing of access rights is easy enough in the application now and quite flexible. Here is an Academy video regarding your question and it contains full description of operations needed to be done to apply right object permissions.Here is also an article regarding setting a business process that will apply access rights even in much more easier way than using object permissions. If you need to change access right dynamicaly - you can create a business process that will change those access rights and also will ask you a question which access rights should be assigned. It can be easily done with the help of "User Dialog" and "Change access rights" elements.
Yes, I know how to use Change access rights to do so. However, it is a confusing implementation, not only for me but also for other members of my team building processes. The display of permission is not consistent in the application or with other displays of access permissions. Typically, there is a single table that displays all permissions and if a checkbox is checked, the value is true and the permission is available, for example, if the checkbox under view is checked then users can view. However, the Change access rights System action violates this. In one section of the dialog, the checkbox means that users can view, while in another section, the opposite is true, leading to confusion and increased training time. The permissions in the Advanced Settings are displayed as I requested, but the Change access rights permissions display in a contradictory manner.
Change access rights business process element was designed to make the process of granting and changing access rights more flexible and so users could ignore using "Object permissions" that are difficult to understand a little bit. Okay, I agree with you that this is hard to work with access rights in our application now so I will create an idea for our R&D team so they could modify changing access rights logic and UI and make it more user-friendly. thank you for reporting this isdea to us!
The code is giving me the result as :
