fusiondirectory issueshttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues2019-01-24T16:49:05Zhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/1671with the latest change for the mailMethod i can no longer log into Fusiondire...2019-01-24T16:49:05Zbmortierwith the latest change for the mailMethod i can no longer log into FusiondirectoryHello,
with the latest change in fusiondirectory for the mail method i can no longer login into fusiondirectory without the mail plugin installed
PHP error ""
Trace[0]: function html_trace File: /usr/share/fusiondirectory/include/funct...Hello,
with the latest change in fusiondirectory for the mail method i can no longer login into fusiondirectory without the mail plugin installed
PHP error ""
Trace[0]: function html_trace File: /usr/share/fusiondirectory/include/functions.inc (Line 133) Type: -
Arguments: -
Trace[1]: function __fusiondirectory_autoload File: (Line ) Type: -
Arguments: "mailMethod"
Trace[2]: function spl_autoload_call File: /usr/share/fusiondirectory/include/class_config.inc (Line 480) Type: -
Arguments: "mailMethod"
Trace[3]: class config / function load_servers File: /usr/share/fusiondirectory/include/class_config.inc (Line 445) Type: method
Arguments: -
Trace[4]: class config / function set_current File: /usr/share/fusiondirectory/html/index.php (Line 250) Type: method
Arguments: "default"
Fatal error: cannot instantiate class 'mailMethod' - try running 'fusiondirectory-setup --update-cache' to fix this
*(from redmine: issue id 1671, created on 2012-12-07, closed on 2012-12-07)*
* Changesets:
* Revision 14ea92408439e166582332b6d96126d08d8ff16a by Benoit MORTIER on 2012-12-07T11:10:04.000Z:
```
Fixes: #1671 with the latest change for the mailMethod i can no longer log into Fusiondirectory
```
* Revision cc8d7294169f5656efd0bf65ef41eeae6f0757ec by Benoit MORTIER on 2012-12-07T11:24:23.000Z:
```
Fixes: #1671 with the latest change for the mailMethod i can no longer log into Fusiondirectory
```
* Custom Fields:
* Bug in version: 1.0.5
* Uploads:
* [0001-Fixes-1671-with-the-latest-change-for-the-mailMethod.patch](/uploads/3784f9ce81afeca1526fa091c72150b3/0001-Fixes-1671-with-the-latest-change-for-the-mailMethod.patch)
* [0002-Fixes-1671-with-the-latest-change-for-the-mailMethod.patch](/uploads/42d824a73c193d6292527d7e644c9d1c/0002-Fixes-1671-with-the-latest-change-for-the-mailMethod.patch)FusionDirectory 1.0.5bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/2225cannot insert mail-fd.schema attribut is missing2019-01-29T15:50:28Zbmortiercannot insert mail-fd.schema attribut is missinghello every things is in title
<pre>
root@infra-ldap-fd:/etc/ldap/schema/fusiondirectory# fusiondirectory-insert-schema . -i mail-fd.schema
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=ext...hello every things is in title
<pre>
root@infra-ldap-fd:/etc/ldap/schema/fusiondirectory# fusiondirectory-insert-schema . -i mail-fd.schema
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
executing 'ldapadd -Y EXTERNAL -H ldapi:/// -f ./mail-fd.ldif'SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=mail-fd,cn=schema,cn=config"
ldap_add: Other (e.g., implementation specific) error (80)
additional info: olcObjectClasses: AttributeType not found: "acl"
Insertion failed!
root@infra-ldap-fd:/etc/ldap/schema/fusiondirectory#
</pre>
more informations
<pre>
root@infra-ldap-fd:/etc/ldap/schema/fusiondirectory# grep acl *
core-fd.schema: DESC 'GOsa acl entry'
cyrus-fd.schema:# cyrus imapd access control list acls work with users and groups
cyrus-fd.schema: DESC 'FusionDirectory - Cyrus acl for folders'
kolab2.schema:# acls work with users and groups
kolab2.schema:# NAME 'acl'
kolab2.schema:# normal user mailboxes can also share folders using acls.
kolab2.schema: MAY ( acl $
mail-fd.schema: gosaVacationMessage $ gosaVacationStart $ gosaVacationStop $ gosaSharedFolderTarget $ acl))
</pre>
version used :
<pre>
root@infra-ldap-fd:/etc/ldap/schema/fusiondirectory# dpkg -l | grep mail | grep schema
ii fusiondirectory-plugin-mail-schema 1.0.5-1~1304021522 LDAP schema for FusionDirectory configuration mail backend
</pre>
*(from redmine: issue id 2225, created on 2013-04-02, closed on 2013-04-04)*
* Custom Fields:
* Bug in version: 1.0.5FusionDirectory 1.0.5https://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/5016Fixing wrong FUNCTIONAL filter2022-09-30T21:24:27ZbmortierFixing wrong FUNCTIONAL filterhello,
we got a fix from github for a non fonctionnal filter
https://github.com/fusiondirectory/fusiondirectory/pull/26
This as to be checked and fixed if the problem is real
Cheers
*(from redmine: issue id 5016, created on 2016-07-...hello,
we got a fix from github for a non fonctionnal filter
https://github.com/fusiondirectory/fusiondirectory/pull/26
This as to be checked and fixed if the problem is real
Cheers
*(from redmine: issue id 5016, created on 2016-07-19, closed on 2016-08-23)*
* Custom Fields:
* Bug in version: 1.0.14FusionDirectory 1.1bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/5810Foreign key on IMAP server is failing2018-04-18T12:44:13ZbmortierForeign key on IMAP server is failing### Description
<!-- Required -->
<!-- Description of the issue -->
When changing the CN of an IMAP server and changing its base at the same time the foreign key on CN is not correctly updated.
### FusionDirectory Version
<!-- Require...### Description
<!-- Required -->
<!-- Description of the issue -->
When changing the CN of an IMAP server and changing its base at the same time the foreign key on CN is not correctly updated.
### FusionDirectory Version
<!-- Required -->
demo-dev
### Steps to Reproduce
<!-- Required -->
1. Create an IMAP server
2. Link it to a user
3. Rename and move the server at the same time
4. Check the gosaMailServer LDAP field value
**Expected behavior:**
<!-- What you expect to happen-->
It should contain the new CN
**Actual behavior:**
It contains the old one
<!-- What actually happens -->
### Additional Information
<!-- optional -->
<!-- Any additional information, configuration or data that might be necessary to reproduce the issue. -->
Also it seems the mail server cache is not cleared as it should.
I’m still openning this in core as the main problem is most likely in the foreignKey system. I will move it if needed.FusionDirectory 1.3bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/5931Use date HTML5 input type for DateAttribute2021-01-29T20:49:02ZbmortierUse date HTML5 input type for DateAttributeFrom #5910
> The hard decision is whether to replace our date input by the type=date HTML5 input. Here is the support matrix: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date#Browser_compatibility
>
> All major bro...From #5910
> The hard decision is whether to replace our date input by the type=date HTML5 input. Here is the support matrix: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date#Browser_compatibility
>
> All major browsers seem to support it, and I expect most of them will have a better interface than our old fashion datepicker. It would mean switching from d.m.Y to YYYY-MM-DD format for POST value. We may keep d.m.Y as internal value to avoid confusing webservice and internal code (but I do think YYYY-MM-DD is a better and more widely used format).
>
> For outdated browser, they would in this case show a text input field and users would have to "guess" they need to enter YYYY-MM-DD format. We can detect this case in javascript and maybe add a text to explain this, or even try to add the old datepicker (but that means adapt its code to support YYYY-MM-DD format). We can use pattern attribute to force NNNN-NN-NN format (with N an integer), which is more widely supported (IE>=10).
I think we should migrate DateAttribute to HTML5 and to `YYYY-MM-DD` internal format. It may break external tools relying on the webservice.
It could break some internal features but this seems unlikely.
I think we should drop the JS datepicker entirely.
This should be done in a major release, so either %"FusionDirectory 1.4" or 1.5.FusionDirectory 1.4bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6116Warning "Cannot use "parent" when current class scope has no parent"2020-10-14T08:58:04ZbmortierWarning "Cannot use "parent" when current class scope has no parent"Another warning when running the setup :
```
Deprecated: Cannot use "parent" when current class scope has no parent in /usr/share/fusiondirectory/plugins/personal/mail/class_mail-methods.inc on line 582
```
Same installation as #6115Another warning when running the setup :
```
Deprecated: Cannot use "parent" when current class scope has no parent in /usr/share/fusiondirectory/plugins/personal/mail/class_mail-methods.inc on line 582
```
Same installation as #6115FusionDirectory 1.4bmortierbmortierhttps://gitlab.fusiondirectory.org/fusiondirectory/fd/-/issues/6160Cannot create Group with mail address using Rest API2023-03-09T15:39:32ZbmortierCannot create Group with mail address using Rest APIHi!
### Description
Using the rest API (https://rest-api.fusiondirectory.info), I cannot create a group with mail address, I get this error [{"message":"This tab does not exists: \"mailGroup\"","line":469,"file":"/usr/share/fusiondirec...Hi!
### Description
Using the rest API (https://rest-api.fusiondirectory.info), I cannot create a group with mail address, I get this error [{"message":"This tab does not exists: \"mailGroup\"","line":469,"file":"/usr/share/fusiondirectory/include/webservice/class_fdRPCService.inc"}]
Mail address can only be added to group on update, never during creation. I've noticed it only happens when the mailGroup tab is placed before the ogroup tab in the posted data (group creation succeeds if the mailGroup is placed after the ogroup).
I don't have this error when adding a user with a mail address when the mailAccount tab is placed before the user tab in the posted data.
Also, I've noticed something strange: setting a mail to a group during update only works if the group contains at least one valid member: having a 'fake' member value such as "cn=empty" (that is set by refint overlay or for synchronization purpose), mail cannot be set using an update request (still the tab does not exists error), and in the UI, the mail tab is not displayed at all, while it's usually greyed.
### Distribution Name and Version
Centos 7
### FusionDirectory Version
Fusion directory 1.4-dev
### PHP version used
PHP 7.4.16
### Steps to Reproduce
(replace base and member to match existing base/user)
```
curl -X POST -H "Session-Token: $FD_TOKEN" https://fd.poc-sync.wsweet.cloud/rest.php/v1/objects/OGROUP -d '{"attrs":{"mailGroup":{"mail":"test-group@wsweet.local"},"ogroup":{"cn":"test-group","base":"o=poc-sync,dc=wsweet,dc=cloud","description":"Liste de diffusion","member":["uid=someone,ou=users,o=poc-sync,dc=wsweet,dc=cloud"]}}}'
[{"message":"This tab does not exists: \"mailGroup\"","line":469,"file":"/usr/share/fusiondirectory/include/webservice/class_fdRPCService.inc"}]
```
**Expected behavior:**
Should work like it does for user creation :
(replace base to match existing base)
```
curl -X POST -H "Session-Token: $FD_TOKEN" https://fd.poc-sync.wsweet.cloud/rest.php/v1/objects/USER -d '{"attrs":{"mailAccount":{"mail":"test-user@wsweet.local"},"user":{"uid":"test-user","givenName":"test","sn":"user","base":"o=poc-sync,dc=wsweet,dc=cloud"}}}'
"uid=test-user,ou=users,o=poc-sync,dc=wsweet,dc=cloud"
```
### Additional Information
I'm testing/using a FD LSC plugin.bmortierbmortier