We have a strange situation and I'm at a loss how to investigate. If user1/securityRole1 gets a resolved case shared (read + share) with them, when they open the case it shows up as readonly (good) but the activity ribbon button is active. This means they can create a new activity regarding the resolved case (by clicking the button which auto populates the regarding field to the read only resolved case).
Meanwhile, the case owner/securityRole2 sees the button greyed out when viewing the case but can create a new activity by File/New/Activity and selecting the case as regarding manually.
User3/admin security role sees the same as the case owner.
If I add admin role to user1 the button gets greyed out and if I take admin role away again, it becomes enabled.
How can this be? Surely user1 cannot gain a right by having a role removed?
Any suggestions much appreciated.
No matter whether Activity ribbon is greyed out or not user can still go to Home > Activities > New and set the resolved case into Regarding of the new activity form.
You might consider adding some javascript / precreate plugin on Create of Activity so that you can throw appropriate error message to the user and prevent the above from happening altogether.
Related
We're working with IBM BPM 8.6.
In many workflows, we do the typical team assignment. The users can claim the task, and work with it. But there is a problem, they cannot assign the task back to the group within the Process Portal.
All we get is a tooltip with the "This action is not permitted" when we try to reassign back to the group.
Reassign back to group disabled image
The same happens if we try to reassign it to an specific user:
Reassign to user disabled image
We know that we could add the following instruction to the workflows:
tw.system.currentTask.reassignBackToRole()
to reassign it back,
but this would affect all the projects, and it would require time and resources to do so.
Any help or hints will be appreciated.
You need to check the "action policies" for the Portal (https://www.ibm.com/support/knowledgecenter/SS8JB4_19.x/com.ibm.wbpm.imuc.doc/topics/restricting_access_to_portal_functions.html). I searched for "process portal action policies" to find the linked page (IBMs URLs can be pretty transient).
The one you're interested in is "ACTION_REASSIGN_TASK". This should be available to all users by default so perhaps it has been changed. You can use was_admin to change or check the values e.g.
wsadmin>AdminConfig.modify(getBPMPolicyAction("ACTION_REASSIGN_TASK"), [["roles", "newrole"]])
wsadmin>AdminConfig.save()
I've upgraded a 1.5 Joomla to actual verison 3.9.x and I have now a special permission problem.
Users are categorized by standard groups, coming with Joomla, so there are 2 super users and some "Managers". Super users usually create articles, managers are finalizing und publishing them.
So, in System -> Global Configuration -> Articles -> Permissions is set to "Edit - Allow" and "Edit state - allow", which means that on every new created article managers can edit the articles.
Now, the super user clicks on Content -> Articles -> New and check that (not-yet-saved) permission tab. The "Calculated permission" shows a green "Allowed" state in "Manager" tab - as set in the global configuration.
Now, the article will be saved, and re-opened, now the permission tab in manager shows RED "Forbidden" although its saved with explicit "Allowed".
When changing and saving the corrected state again (on the existing article), the permissions are set correctly and the managers can edit the article.
In the actual state, the super user must create an article, close and re-open it and set the right permissions to make it available to other backend users.
How can I fix that?
My guess:
On the first save, the permissions are not set correctly, so Joomla is using "fallback permissions" which means that just super users can edit that article.
Edit:
Here's an interesting comment in joomla core source code, where permissions are saved:
#to do: incorrect info When creating a new item (not saving) it uses the calculated permissions from the component (item <-> component <-> global config).
But if we have a section too (item <-> section(s) <-> component <-> global config) this is not correct.
Also, currently it uses the component permission, but should use the calculated permissions for achild of the component/section.
Try to open and save your superusers. This might at least correct any issue with the actual user, that arised after your wishful upgrade attempt :)
If there are many issues after your upgrade, and your web site is not huge, i would consider doing a fresh install of the latest Joomla, and importing data in a more manual /semi manual way. Else I guess you'll be having issues for a while...
We have table Transfer Order:
This is the view from admin User.
This is the view of the user to whom I need to give read , write, create and delete access, but the two fields 'To Stockroom' and 'From Stockroom' are not visible to this user.
I have created ACLs like:
how I can make these two fields accessible to some user?
Please help me.
In order to find the specific ACL that is failing the user's request for access, you can simply enable the Debug Security module. Then impersonate the user, visit the record, and scroll down the page. You'll eventually come to a line like this:
This red X indicates that a condition of the ACL was not met. Clicking the ACL (In this case, record/alm_asset.model/write) will take you to the specific security rule. Hovering over the red X will tell you what portion of the ACL was not met; the condition, the script, or the role requirement. That is what you must remedy either in the ACL, or by granting the user the necessary permissions.
I suspect in your case, that the user is able to see the record they're viewing, but does not have access to view the record or table referenced in the reference field. However, only the ACL/security debugger can tell you for sure.
To stop debugging, just click the "stop debugging" module in the app navigator, or log out of ServiceNow.
I understand that a plugin registered for pre-validation executes outside of the database transaction but I'm not sure I can think of a scenario when this would be preferable to pre-operation. Can someone give me an example of where pre-validation registration might be useful?
We have a few plugins registered on the 'PreValidation' event although this is on premise, not online.
I did not write these specific plugins myself but I can describe one and give the justification for using 'PreValidation' rather than 'PreOperation'.
Entity: Account
Event: Delete
Logic: Plugin runs pre validation. Checks that there are no contacts referencing any of the account's addresses. If any are found, stop execution. If not, delete account.
e.g.
Account 'Stackoverflow' has address 'Jeff Attwood's House' and Contact 'glosrob'. 'glosrob' is referencing 'Jeff Attwood's House' through a customisation. If a user selects to delete 'StackOverflow', we should detect 'glosrob' is referencing an address and prevent the delete.
The reasoning behind this was the developer found that at the PreOperation stage, some aspects of the delete had already happened, namely the cascade deletes. The logic of the plugin requires us to check all contacts - by registering at PreOperation, contacts under the account had already been deleted, rendering the check obsolete.
In our previous scenario, when the user selected to delete 'StackOverflow' Account, the Contact 'glosrob' would be deleted before the plugin runs. Therefore when the plugin did run afterwards, it would allow the delete.
As with most things in CRM, it all comes down to requirements and solutions, but I think that gives you an idea of why/when you might use a PreValidation stage. We have a few others with similar reasoning that run on the 'Delete' event.
I know its very old post, came here while digging for an answer for the same question...
Later I found one key point from MSDN on the same topic and i thought it would be helpful If I post the infromation over here for all..
The Prevalidation plugin would happen prior to the security checks. For ex: If an account is "VIP" account and you dont want this account record to be deleted (no matter even he is a super user/admin), then this better can happen in pre validation. Because at that time you are not really bothered about who the user is and what sort of permissions he has (even he may not have any permissions to delete any records in the system), CRM will go and check the database for the user's security roles during the pre operation and that is where the first database hit would happen.. before that it self, we can stop the exucution of the plugin based on our validation rules..
I hope that make sense...
Thank you
Regards
Srikanth
Is it possible to stop the back button from working during a data call? For instance, when registering, I don't want someone to press the back button otherwise they may register for my service and not know it (other than confirmation email)? (And the registration will fail the next time they try)
Handle the BackKeyPress event or override the OnBackKeyPress method in your page class, and then set e.Handled = true; when you want to prevent backwards navigation.
Note that if you do this, then you should provide the user with a way to cancel your long-running process so they can back out if they want to.
Please note that if you stop the Back button from working your application will fail marketplace submission.
See section 5.2.4 Use of Back Button.
If a user has the situation where they try to reregister (becuase they don't realise they have registered previously) then you should handle this in your app as the situation may come up anyway.