I am getting following error from Retention Policy Deletion:
"Folder can’t be locked since its hierarchy contains locked document"
I am not sure how were these documents locked and how can I unlock them again.
Also, will unlocking them cause any data issues?
Help will be greatly appreciated.
Regards
Retention Policies should only try to delete documents older than whatever you have configured (by date of last access). So if this document were locked by normal use in the system, then it should have a recent last access date and not be ready for removal by retention policies.
Thus this is probably a problem occurring in the product. You will need to open a technical support case so Kofax can diagnose the problem. In all likelihood, the support team can provide a SQL script to unlock the documents once they make sure there are no other problems. But you should not do it on your own since it is not supported and, yes, it is possible to cause data issues by modifying the database.
Related
In salesforce, we have a scenario, on the trigger of the lead object we are updating some records of Campaign. But the user on the behalf of we are running the trigger does not have edit permissions on the campaign. We are not facing any issue in the update of the campaign because the trigger is running the operation in system mode.
Further, we have applied for the security review and made the changes and added the check of the object isUpdatable() and after it, we are not able to update the campaign due to that check which returns false for isUpdatable().
My questions are, Can we pass the security review without applying that isUpdatable() check? if our process has the business logic to update the campaign/opportunity on the behalf of the user who doesn't have permissions on the campaign/opportunity?
If we can not pass the security review with that check then what could be an alternative for it, where one user who doesn't have permission on campaign/opportunity, performs some operation on lead/contact and we want to update the campaign/opportunity in system mode after that operation?
or is it necessary to provide the permissions of campaign/opportunity to that user?
It's not a coding question as such so it might be closed here. Consider cross-posting to https://salesforce.stackexchange.com/
Generally speaking, your app should be simplifying Salesforce. Adding value by being pre-built, pre-tested use case for this customer and saving clicks for the end user. (let's ignore situations like pulling data from other systems, runinng some crazy Excel file generation that SF can't do easily). With that philosophy - you're supposed to respect the System Administrator's wishes when it comes to security. If admin didn't grant Profile X edit access to field Y - the security review answer is that you should detect it. If you can recover gracefully and continue with your program - cool. If it's critical field - throw an error, force the admin to make conscious decision. Because if you're saving clicks - user would face same problem in normal UI. It's not only "describes", it's also about "without sharing" for example.
There's another layer to it - licensing. In the old days "Marketing User" (to access campaigns) was a separate license, you assigned it by clicking checkbox on User but it had to be purchased. Now it's bit simpler, part of the full user license (I think). But there are still situations where you can't access Opportunities for example (Platform License) or can access only Account, Contact and 10 custom objects (Chatter Plus License or whatever is the new name).
If you abuse system mode to fetch data from objects user is not allowed to see (or save to them) - official answer is that SF loses money because of you. Permission should really be assigned and if needed - license purchased. I'm not a lawyer, I don't know who violates the Master Service Agreement with Salesforce, you or the client that installed the app or both. I'd say read the contracts and see what you can do to protect yourself. If that means your app can't be installed by customers on Essentials/Professional (or it can be installed anywhere but can be used only by full users, not by Platform/Chatter/Community) - well, it is what it is. Decide pros and cons, legal consequences if it gets caught...
They're humans, talk with them. Maybe you'll pass review. Better have a rock solid business case why you need to bypass the check though.
P.S. You know you don't have to do describes anymore? Spring'20 goes live this & next week and "WITH SECURITY ENFORCED" and "stripinaccessiblefields" become generally available :)
P.P.S you really need trigger? Workflow, process builder, flow (yuck) - anything to not have code = not need the isAccessible and if it effectively dies on permissions - it's the client's sysadmin's problem?
Short version: (after finding out the answer)
I have an Excel VBA application with an MS Access database (.accdb) on a SharePoint library.
The behavior that was examined (and apparently documented - see answer):
It takes a long time to perform the ADODB Open and Close methods (~15 seconds).
If multiple users are connected at the same time to the database, only the changes made by the user which closed the database connection LAST are saved. Changing cursor types, cursor locations or lock types didn't help. No error shown.
Why does this happen?
Original Question:
First question here. Hope this isn't too wordy:
I've built an Excel application using VBA to communicate with an MS Access database (.accdb) that should have support for concurrent users accessing it. It is meant to be placed on a Sharepoint site as an accessible file (not integrated into it in any other way). When I was testing the Excel file and the database on my home network it worked like a charm, transactions and all. However, once I migrated it to Sharepoint, I've noticed some extreme differences from the way it acted on my personal network:
The ADODB {.open} and {.close} methods take at least 15 seconds each (making Excel freeze until done). Due to this, I've decided to open and close connections only once throughout the lifetime of the application, and restore the connection if it is broken along the way. I'm aware of the fact that this is highly not recommended, but can't afford having my users wait so long. This hasn't caused any problems that I'm aware of, perhaps apart from the one I'm about to explain.
The problem: Changes aren't saved to the actual database unless all active user connections to the database are closed, even if the only active thing is the connection. Everything passes without errors for each user when attempting to update, and each user can access his/her changes, I suppose until all connections are terminated. I tried all possible cursor types and lock types, nothing seemed to work. It is as if a local copy of the database is stored on the user's computer (hence the long wait while opening and closing the connection), and updates are stored on the temporary version, not the actual one.
I tried all possible combinations for cursor types, cursor locations, lock types and what not (found out along the way that dynamic cursors aren't supported in my case - I wonder if that's the answer).
Due to this I have no other choice but to make the program accessible to only one user at a time, or changes seem to get lost along the way, making the program highly unreliable.
I read something about having to "flush the buffer" or "refresh the cursor". Is this even possible/necessary? Or the case? If I'm using a keyset cursor, shouldn't my edited records be shown to all other users? (not talking about new ones)
For what it's worth, I map the path to the sharepoint folder before accessing it.
Have any of you experienced something like this? Or have any suggestions?
If you need samples of my code I'll post it soon. Thanks so much!
I found the solution to my problem:
Although you can save an Access database file to OneDrive or a SharePoint document library, we recommend that you avoid opening an Access database from these locations. The file may be downloaded locally for editing and then uploaded again once you save your changes to SharePoint. If more than one person opens the Access database from SharePoint, multiple copies of the database may get created and some unexpected behaviors may occur. This recommendation applies to all types of Access files including a single database, a split database, and the .accdb, .accdc, .accde, and .accdr file formats. For more information on deploying Access, see Deploy an Access application.
Source: Ways to share an Access desktop database
Out of the box, does Guidewire support term change without a policy rewrite?
Is there anyway I can test this on my local?
Thanks in advance!
No. Guidewire does not support policy term change without rewrite OOTB. You have to cancel the policy and rewrite in order to change.
I know this question is a bit old and I'm sure you've come to whatever answer you needed, but just in case someone else lands here in the future...
From an insurance point of view, there are a couple different versions of "changing the term". If the policy was originally entered/issued with the wrong term by accident, yes you likely need to just flat cancel and re-write it. There are a few legitimate situations where the "term" could change where nothing about the policy was ever invalid and shouldn't require a re-write/re-issue. One example is extending the term, common in construction projects. You wouldn't want to write a whole new policy for a couple week extension of a project that ran long. Another situation is more correctly termed "Extended Reporting Period" for certain types of professional liability policies that operate as "claims made". I've seen ERPs done as either a separate, but attached policy, or as a very special type of endorsement that gives a wider effective/expiration date as it relates to claims made policies. The last scenario I've run into as a consultant and as an insured is the need to "move" the effective/expiration based on a home purchase for a home owners policy when the closing date gets moved. In that circumstance we only ever processed those on bound, but not yet issued policies.
As for native Guidewire, I'm not able to answer that one as the last implementation project I worked on had started a few months before I was brought on board and that functionality was already there.
Side note, any time you are in a situation of altering term/effective periods of a policy, it is important to verify if there are any open/closed/pending claims impacted. We had one situation where the policy term simply had been entered wrong, but issued correctly from the MGA. The carrier denied a claim due to it being outside of the term a day or two before the policy was fixed. It was a week or two later when everyone realized what happened and the claim was also fixed after the insured's lawyer contacted the carrier for incorrectly denying the claim. All was eventually resolved though.
I am evaluating GitLab for my enterprise, I really hope my assumption is wrong here because I REALLY like the product.
For my enterprise, the built in permissions are far to open. We could lose about 2 or 3 industry certifications due to failed security audits if we turned it on with those permission levels and permissions per level.
How do I create my own security levels? Guest and Reporter need purged from the system completely. Enterprise Security would crucify me in the front lobby if I put those in. Then Developer needs slashed way back in permissions, master needs slashed way back, and I need to create maybe 3 more specialists.
I know there isn't a UI to do this, but please tell me there's a file somewhere I can edit to do this. I hate to be forced to spend 5X as much for GitHub for this single issue.
A custom system is in discussion for quite some time now. See the discussion here. Right now the only way you can modify rights is by editing the file ability.rb which contains what permission a group has.
def project_owner_rules for instance defines what permissions the project owner has.
Keep in mind that this file will be overwritten with every update if you make changes, so keep a copy of your modifications around.
Is it possible to query historical data from Active Directory? Does it keep it?
Can I execute anything like this:
Get User's Direct Reports
http://msdn.microsoft.com/en-us/library/windowsazure/dn151686.aspx
to find out the list of the user’s direct reports for a day in the past?
No.
Currently (as of November the 6th 2013) there is no such option/feature in the WAAD.
The feature that I expect to see in the future releases (and is totally my speculation and expectation) is related more to auditing logs (such as who did what and when), which might eventually help you.