Non-admin users unable to edit existing accounts, opportunities, contacts, etc

[badmin]

Sugar Version : 5.2.0a (Build 5447)
Sugar Edition: CE
Category: Accounts, Opportunities, Leads, Contacts
Operating System: CentOS 5.x (2.6.18-8.1.6.el5 #1 SMP Thu Jun 14 17:46:09 EDT 2007 i686 i686 i386 GNU/Linux)
PHP Version (e.g. 4.3.11, 5.1.2)
Database: mysql Ver 14.12 Distrib 5.0.45, for redhat-linux-gnu (i686) using readline 5.0
Web Server: Apache/2.2.3 (CentOS)


I am unable to edit accounts, leads, contacts, and opportunities when logged in as a non-admin user. For example, if I log in as a non-admin user and select an existing account from the listview and then click "Edit", it looks like when I click the "Edit" button on the DetailView page it attempts to go to the EditView but immediately redirects back to DetailView.

I'm not using roles. I am using Teams CE.

[stevec]

Sounds like a teamsCE thing - best bet may be to ask the author. But a guess would be that you have created the records as an admin and the default is to set the record's team membership to an admin-type team rather than the global-type team.

I'm bring a bit vague with the names as I don't use teamsCE - but the problem sounds like what would happen in sugar PRO with it's own teams subsystem if the creating user's default team is set to private rather than global. In that case, the record is saved so that only that team's members can access it. Whereas, using global allows everybody.

[mvngti]

You will need to give me some more info to work with but it sounds like CE Teams is redirecting you back to DetailView. This is quite strange because the same logic that restricts the EditView should also restrict the DetailView.

Which team is the record assigned to? Is the current user a member of that team? etc. etc.

M

[mvngti]

PS: Are you using Teams CE (an alpha follow up of TeamsOS) or my CE Teams module?

[badmin]

You will need to give me some more info to work with but it sounds like CE Teams is redirecting you back to DetailView. This is quite strange because the same logic that restricts the EditView should also restrict the DetailView.

Which team is the record assigned to? Is the current user a member of that team? etc. etc.

M

I didn't realize there is a Teams CE and a CE Teams. Yes, I'm using your "CE Teams" version 0.98.12338. And, yes the record is assigned to the same team as the user trying to edit it, and additionally the record is assigned to that user.

So, User A is a member of Team X.
The record R is assigned to Team X and record R is assigned to User A.
User A is a non-admin user.
User A cannot edit record R.
Other members of Team X cannot edit record R.
Admin can edit record R.

[badmin]

The problem seems to be related to the last if-statement in the check_team_access function of teams_logic.php

// Prevent empty editview if user go directly to edit
if (is_null($bean->id) && $_REQUEST['action'] == 'EditView')
header ("Location: index.php?module=".$_REQUEST['module']."&action=DetailView&record=".
$_REQUEST['record']);


When I comment that section out, the users are once again able to edit their records. So it looks like $bean->id is null, but what would be causing that?

[mvngti]

Have a look at the code immediatly above what you have commented out!
By commenting it out you are defeating the object of the module - to restrict access!

$bean->id will ONLY be null of the code above set it to null and that would only happen if the user is NOT allowed to see the record!

You have another problem somewhere - the module is supposed to restrict the access - that is what it does!

[badmin]

Yes, I realized that. After making the changes I did test them out. The module was still restricting the records returned during searches. The only time someone would be able to access a record that isn't assigned to their team was if they accessed the url directly, but they were still prevented from editing it. If they tried to edit it, the result was that a new entry was created with a new ID in the system and assigned to the user and team that tried to edit the original record.

So basically, the only change in functionality was that a user from another team could copy the record by trying to edit it... but that could be done manually anyway, since the code that I commented out was just redirecting to the DetailView where all the information already existed. An offending user could simply take the data from the DetailView and create a new entry using that data.

The reason I took that step is that I in all cases, the $bean->id shouldn't have been null. The users were correctly added and assigned to the correct teams, and the accounts, contacts, etc, were also assigned to the same teams and users. I checked this countless times in the database tables themselves.

Still, I realize my solution is not ideal, but still met our needs until a better solution is found. The functionality that WAS retained was doing what we needed anyway.

In any case, I appreciate all of your previous help, and if I find out what the root cause of the problem is, I'll be sure to post again.