webservice: object is modified instead of created

When creating an org with:

$odata['organization']['o'] = 'xxx';
$odata['organization']['description'] = ...
$odata['organization']...

$fdresult = $client->setfields($session_id, 'organization', NULL, $odata);

Note that I'm using 'NULL' because I want to create a new org.

In LDAP logs I get this 'new' string to appear :

... filter="(&(?roleOccupant=new)(&(objectClass=organizationalRole)(!(objectClass=simpleSecurityObject))))"
...
filter="(&(?member=new)(objectClass=groupOfNames))"
...
conn=18049 op=1 do_search: invalid dn: "new"

(Once again I do not get zero error back from the webservice about this...)

The final result is if the organization 'o=xxx' already exists, it is somehow modified instead of created as asked (ie: it should raise an error that this org entry already exists).

Oct 21 11:00:06 fd slapd[20551]: conn=18049 op=7 MOD dn="o=xxx,ou=organizations,dc=ow2,dc=org"
Oct 21 11:00:06 fd slapd[20551]: conn=18049 op=7 MOD attr=objectClass fdCommunityMembershipType fdCommunityMembershipActive fdCommunityMembershipHidden fdCommunityStartDate fdOrganizationAlternateAddress fdOrganizationAlternateCity fdOrganizationAlternateCountry
Oct 21 11:00:06 fd slapd[20551]: conn=18049 op=7 RESULT tag=103 err=0 text=

(from redmine: issue id 5196, created on 2016-10-21, closed on 2016-11-03)

• Custom Fields:
  • Bug in version: 1.0.16
  • Support contract: None

Solving this bug is not a priority for me (as I can check for this org before creating it as a workaround), but in general this behavior can lead to unexpected object modification.

(from redmine: written on 2016-10-21)

By mhamant on 2017-09-02T15:33:59 (imported from GitLab)

I added a check to avoid searches on member=new, but that has nothing to do with an entry being modified instead of opened.

(from redmine: written on 2016-10-24)

By Côme Chilliet on 2017-09-02T15:34:00 (imported from GitLab)

Hi Come, Thanks. I might have mixed up things a little bit, but here is my observations when using the above code :

• if the organization 'o=xxx' already exists, it is somehow modified instead of created (ie: it should raise an error that the org entry already exists instead, no ?).
• that's not my choice to "search for member=new", I just use setfields() as in the above code with 'NULL' as DN (third arg). I don't mention "new" anywhere in my code nor data.

(from redmine: written on 2016-10-24)

By mhamant on 2017-09-02T15:34:00 (imported from GitLab)

Martin H wrote:

• if the organization 'o=xxx' already exists, it is somehow modified instead of created (ie: it should raise an error that the org entry already exists instead, no ?). Yes that’s the real issue, I need to test this, that’s why bug is still open and low in %
• that's not my choice to "search for member=new", I just use setfields() as in the above code with 'NULL' as DN (third arg). I don't mention "new" anywhere in my code nor data. Any created object have dn "new" until it’s saved, and the groups and roles tab was searching for the dn in roles and groups anyway so I assumed this was the origin of your logged LDAP searches. If it happens when creating an organization it’s a bit weird through, it should be when creating a user.

(from redmine: written on 2016-10-24)

By Côme Chilliet on 2017-09-02T15:34:00 (imported from GitLab)

Seems fixed in 1.0.16-2~jenkinsbuild487... I get the (expected) message "The entry 'o=xx,ou=yy,dc=ow2,dc=org' already use this 'Name of organization' attribute!" If you haven't done any fix for this specific issue I feel a bit dumb because I've well tested the issue before reporting.

(from redmine: written on 2016-11-03)

By mhamant on 2017-09-02T15:34:00 (imported from GitLab)

I can reproduce the issue at least on demo.fusiondirectory.org (1.0.16) and got some details: It seems the MOD was happening only on fdCommunityXXX and fdOrganizationXXX attributes (as shown in the LDAP log in the initial issue description).

I still use the following code but on demo.fusiondirectory.org:

$org = 'altic2';
$odata['organization']['base'] = 'dc=fusiondirectory,dc=org';
$odata['organization']['o'] = strtolower(preg_replace('/[^a-zA-Z0-9-_\.]/','', $org));
$odata['organization']['description'] = "Description super org modif";
$odata['organization']['postalAddress'] = "blou\nbla\nblimodif";
$odata['communityOrganization']['fdOrganizationAlternateCity'] = "Lyon2";
$odata['communityOrganization']['fdOrganizationAlternateCountry'] = "France4";
$fdresult = $client->setfields($session_id, 'organization', NULL, $odata);

I run it twice. On second time I change the values of attributes to see what's happen:

• First time the org is created. No problem
• Second time description and postalAddress is left unchanged, fdOrganizationAlternateCity and fdOrganizationAlternateCountry are modified

(from redmine: written on 2016-11-03)

By mhamant on 2017-09-02T15:34:01 (imported from GitLab)

hello,

you tell us its fixed in 1.0.16-2~jenkinsbuild487, can you test then against demo-fixes, if its corrected will close this bug

Cheers

(from redmine: written on 2016-11-03)

By bmortier on 2017-09-02T15:34:01 (imported from GitLab)

It is fixed on demo-fixes. I was just informing in my previous comment that the bug was real in 1.0.16.

(from redmine: written on 2016-11-03)

By mhamant on 2017-09-02T15:34:01 (imported from GitLab)

hello,

ok closing it then

Cheers

Close issue

(from redmine: written on 2016-11-03)

By bmortier on 2017-09-02T15:34:02 (imported from GitLab)

closed

By bmortier on 2017-09-02T15:34:02 (imported from GitLab)

added Fixed label

By bmortier on 2018-09-27T18:54:53 (imported from GitLab)