As I am digging deeper it seems to be associated with their ROLE. If I switch their role they can see the calendar again. Is it possible their is a bad record that is affecting their whole view?
Rich. That error looks like it is coming from umps-min.js I don’t think that is part of the Skuid package. I’m not saying that for sure, but might that direct you toward another package that could be throwing the error?
Rich, can you Grant Login Access so that we can take a look in more detail? Also send us the name of the page where this is happening and which User this is happening for.
From the error messages we are seeing, it does look like a Sharing-related issue. Shot in the dark here, but possibly there is a Sharing Rule in your org that is associated with an inactive User, perhaps a Sharing Rule on the Account or Contact objects? From the errors we’re getting that’s my best guess at this point.
Thanks Zach, any assistance or direction is appreciated! I am granting you access now.
It seems to be isolated to the Provo Area Director role branch. It seems like that contaminates the view somehow. If the Nephi Area director is assigned they can see the calendar but when Provo is down stream they cannot.
The name of the page is AreaCalendar
I have one user that can see the Provo calendar. All others get the same error. Don’t know what that means but it is a clue.
I have been troubleshooting for hours and have a couple interesting findings.
1. I don’t think that error code has anything to do with the problem. It seems to be more related to me logging in AS the user. Since the error code displays on any page I load when logged in AS the user (for troubleshooting purposes).
2. I created a clone of the Calendar and removed models one by one and isolated the model that appears to be causing the problems “Medical Calendar”
3. I played with date range filters and thought I narrowed it down to an appointment on 2/26/15 at 9:00 AM based on the fact that if it was 9:00AM I would get the SQLException in (skuid) error and if it was 9:05AM it would load just fine. I deleted the 9:00 appointment and still got the same behavior. Odd…
4. Currently my max # of records (Limit) was set to 1000. If I change it to 999 the page loads fine with no SQLException in (skuid). If I put it to 1000 I get the error page SQLException in (skuid). Keep in mind though this is only happening for users whose roles are set to Provo. I can see all data and it loads fine when it is set to 1000 records. And it loads fine for other users that have access to more records than just Provo. I am just saying it is not a HEAP error or it would be happening to other profiles that load in more data.
So for now I just changed the max records to 999 and that is my mid term fix. It would be nice to know what is going on though so it doesn’t break again.
Can you intuit anything based on the new information?
Rich, the fact that changing from 1000 to 999 made the error go away is very helpful in getting at the cause of the issue.
From all of the troubleshooting steps you’ve taken, and from the error messages that you are receiving, the issue appears to be related at a root level to the evaluation of Sharing upon the Event records in question. I have seen many error messages that occur when non-Admin users attempt to query Models on Standard Objects with a Limit of 1000+ ---- usually these errors surface as “Implementation Restriction: only allows security evaluation for non-admin users when LIMIT is specified and at most 1000”. Here though you’re getting an untrappable Oracle SQLException, which is bad — this needs to be reported to Salesforce as a bug. Salesforce users should never encounter underlying Oracle PL/SQL errors such as the one you’re getting.
However, my guess is that once / if Salesforce were to fix this bug, you would start getting an error something like the “Implementation Restriction” error I quoted above, and that you’d have to have a limit of 1000 records on your Model anyway.
So I think there’s 2 steps to take:
- I recommend reporting this to Salesforce as a bug by logging a case.
- Retain the limit of 999 on your Medical Events model, and in the future make sure that your limits are no more than 999. In general it’s probably not a good user experience to have 1000+ Calendar events showing up for a given Event Source anyway.
I am not sure if you are seeing the same error messages that we are, but here is the error message we’re receiving on our end:
common.exception.SqlDupValOnIndexException: ORA-00001: unique constraint (CORE.AKTMPD_ID2_LIST_IDX) violated Insert into /* ActivitySharingDirect / core.tmpd_id2_list_idx (entity_id) (select contact_id from sales.contact where organization_id = ‘00D0000000ABCD’ and account_id = ‘000000000000000’ and owner = ? union all select c.contact_id from (select /+ ordered no_merge */ distinct s.account_id from core.direct_group_member dgm, core.group_blowout gb, sales.acc_share s where dgm.organization_id = ‘00D0000000ABCD’ and gb.organization_id = ‘00D0000000ABCD’ and s.organization_id = ‘00D0000000ABCD’ and dgm.member_id = ? and dgm.ug_id = gb.component_ug_id and gb.ug_id = s.ug_id ) s2, sales.contact c where c.organization_id = ‘00D0000000ABCD’ and c.account_id = s2.account_id )
where I have inserted 00D0000000ABCD for your company’s actual Org Id — if you send this error message Salesforce in a bug report with a subject something like this, I think it will get their attention:
“Summer 15 causing common.exception.SqlDupValOnIndexException to be thrown”
And then in your bug report paste in the full content of the error message above, replacing 00D0000000ABCD with your actual Org Id, and give them all of the information you’ve given us.
Regards,
Zach
The odd thing is, I have a number of users that are NOT admin, but if I change their role to Provo they could still see the calendar where the others could not. I could take one user that could not see the calendar and change their role and profile and permissions to the same thing as the user that could see and they still cannot see. On the other hand I can take another user and change their settings to the same role, profile and and permissions and they can see the calendar fine. I love computers because they are so logical, but this one baffles me since I am not able to see a common logic. If the error is anything over 1000 all my areas should be having the same problem. It is odd that a subset of users is having the error when I have larger areas with more calendar items that are not. Also, I thought the calendar object only queried the month that was shown and then requeried every time you changed months is that the case?
It is strange — there’s definitely a Salesforce bug occurring that needs to be fixed. I would expect the same issue to be occurring for all non-admin users who share the same type of security settings: Role, Profile, User License type. I looked into the security setup for users in the Provo group, and my only suspicion was that the users who had the “Chatter Only” License Type might be the ones who were causing the problem. However it looks like there are 8 users who are members of Public Groups in your org who have Chatter Only licenses, so I would assume that the same issue would be occurring for them. I agree, I don’t see any common logic.
