Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - markc

Pages: 1 2 [3] 4
31
Community Contributions / New version of previous vcard submission
« on: July 27, 2010, 07:33:21 pm »
See here for background:

http://forums.fengoffice.com/index.php?topic=3714.0

I've done a re-write of the previous version. I also have a version of the patch that adds a second and third address line to each address (see http://forums.fengoffice.com/index.php?topic=3919.0 ) and because I also have several versions for 1.6.2 and 1.7 in various states of completion...the scope is getting a bit beyond me. I'm not quite as sure about this version because I can't as easily visualize all versions of my entire code. It has gotten a bit big to keep my head wrapped around, but I think I'm just imagining problems at this point. I'm an IT guy, not a coder!  :)

However! I'm pleased to say that the code works great for us; much better than the last one (which went into 1.7). Some examples of the improvement is that it can classify phone numbers better, it understands parameters better ( "TYPE=HOME,WORK;" and "TYPE=HOME;TYPE=WORK" come out looking the same! ), and for contacts that are already in FO it can usually do a lossless export and reimport including FO only fields. It tags those FO only fields as custom in the export and the importer knows where to look. AFAIK the way it does this is within the vcard spec.

It is commented out for a later version, but this code was also close to being able to handle strings that are have their own delimiter escaped within a field. The regex matches odd or even numbers of backslashes to tell preg_match_all() whether to break to the next field or print the backslashes and the delimiter literally. Didn't quite get that part working.

I'm going to attach four versions of "v2 final", if you will. At one point each one was thoroughly tested and I THINK I've kept them cleanly applying to their various code-bases. You might be able to apply them and use them in production straight-out, but I'm only using the last one from here on out.

Since my patch list has been growing it is my hope that the vcard part will get committed, and that maybe even the devs will see value in having two more address lines in the contacts object (since vcard supports it and that support is already working in that version of this patch). It'd let me juggle less but I suppose I'll live if I have to keep updating these patches myself to your new versions. :)

Same patch instructions as the last version. I think that is about it. Let me know if you have any questions.

Hope these help,
Mark

1. vcard v2 for 1.6.2
2. vcard v2 for 1.6.2 w/ address line 2/3 expansion
3. vcard v2 for 1.7
4. vcard v2 for 1.7 w/ address line 2/3 expansion    <(in production!)

32
Getting Started / Re: Active Directory Integration
« on: July 27, 2010, 06:21:08 pm »
I'm in the same boat. I tried using an AD group too, but it choked. We need it to try multiple OUs. This would make a great feature request, I just haven't gotten around to it.

33
I'm not sure this will be the end all fix but I do believe you are misusing that uid field and I can explain it a little bit.

That field is intended to identify which field in your AD user object fengoffice should use for the username. This is needed because depending on how you enter new users, each user's CN may not match it's sAMAccountName. Some interfaces or scripting tools will let you create a user without specifying a first and last name. In that case the CN usually matches the sAMAccountName. However in the case where a first and last name are entered the CN may be Bob Jones and the sAMAccountName could be bobjones. These are not even the only two fields in your user objects that could be suggested for use!

That line for me says:
Code: [Select]
'uid'       => 'sAMAccountName'
...and that makes it so that FO expects the username to be the same thing the user logs into their workstation with, instead of their pretty freetext CN or perhaps their sid or some other more difficult field.

Finally note that some people log into Windows domain workstations as bobjones@yourdomain.com, which is usually their email address. It works to get into the machine but, sAMAccountName won't work for that in fengoffice. I'm pretty sure that version of the username is called 'userPrincipalName', yet another field you could use!

HTH
Mark

34
Development / Re: LDAP 1.7 RC
« on: May 26, 2010, 05:44:17 pm »
I guess late is better than never...

If you're still on this could you please post what you've got for the ldap config?

35
Getting Started / Re: LDAP Authentication on 1.7.Beta2
« on: April 09, 2010, 12:43:32 am »
Glad to see the that fixing the uid parameter worked! :)

Not sure about your SSL issue. Need a client-side cert. or something? I've only really set up openvpn before when it comes to using SSL...so I dunno.

The MySQL thing for your users is normal. The patch checks MySQL first to make sure that the username is valid in F.O. and then looks up that user in ldap and sees if that user can bind to ldap. This is so that some random user in ldap won't be allowed in F.O. even if they have no account there.

I usually let F.O. assign a random password and turn off the email notification on new user creation. Since it is already in ldap I just tell people to use the login they use for everything else, so they don't need the email.

36
Getting Started / Re: LDAP Authentication on 1.7.Beta2
« on: April 05, 2010, 12:37:45 pm »
Well, does it work if you turn off the ssl?

37
Getting Started / Re: LDAP Authentication on 1.7.Beta2
« on: April 04, 2010, 05:34:12 pm »
I don't think it is your current issue but one thing is that I think your uid parameter is incorrect. Unless something has changed (I'm on 1.6.2), the uid parameter says which field in LDAP should be used to validate the username. That is, if you try to log in as joebob1 your current config would tell fengoffice to look in LDAP for a field named admin, which probably isn't there. I think it is usually just 'cn' for the common name field in LDAP, but it could be different. Since I'm using AD and the cn field isn't consistent, I've got mine set to 'sAMAccountName'.

Next...just to be certain...does your config actually say dc=example,dc=com or are you just giving that as the example in this post?

HTH,
Mark

38
Okay so I have some progress on this. I'm attaching a patch that makes some changes, mainly to address handling, and so far the addresses are exporting and importing correctly for me. ymmv.

Changes:
1. As I'd said previously the export function was printing commas and as far as I can tell that is out of spec. So I've changed the export function to delimit fields with semi-colon. (which is what import was looking for anyway)

2. The vcard 3.0 spec also seems to now frown upon printing charset data as a parameter inline with the vcard data. So I've taken those out of the export function. However I noticed that in the import function it is an OR, and that if it finds the charset data it does nothing with it. If it isn't there then no problem. That doesn't hurt anything so I've left it in there.

3. The original address regex:
Code: [Select]
  } else if (preg_match('/ADR;type=(HOME|WORK)[,A-Z]*;(charset=[-a-zA-Z0-9.]+|type=pref):;;([^;]*);([^;]*);([^;]*);([^;]*);([^;]*)/i', $line, $matches)only matches if the type is home or work AND OPTIONALLY something else. It seems to me (and my testing showed) that it won't match/function at all if the type is simply Other, or Parcel, or (what the export function prints) INTL. I've changed it to be:
Code: [Select]
  } else if (preg_match('/ADR;type=(HOME|WORK|[A-Z0-9]*)[,A-Z]*(:|;charset=[-a-zA-Z0-9.]+:|;type=pref:)([^;]*);([^;]*);([^;]*);([^;]*);([^;]*);([^;]*);to match work or home OR other, and then allow for additional fields after that. It isn't perfect, such as when there is a distinct work and home address but Parcel, Post, Pref etc are listed first in the type= field.

3.a Also in the same lines...the regexes for the other vcard lines allowed the option of the charset field "(:|;charset...", but the ADR line assumed it to be there (or a type=pref directive). So I made it like the others to (hopefully) also be more flexible.

4.
Code: [Select]
-  } else if (preg_match('/URL(;type=(HOME|WORK))?.*:(.+)/i', $line, $matches)) {
+  } else if (preg_match('/URL(;type=(HOME|WORK))?.*?:(.+)/i', $line, $matches)) {
just switches another one of the regex operators to be lazy, so that given "URL:http://www.something.com" it will now find the first colon and not cut off half the field.

I'm still seeing some phone numbers and other fields end up in different places after exporting and re-importing a contact, and I didn't touch the photo stuff. I'll probably do a little more but I didn't want to wait and have a ten page post all at the end.

As always let me know if you have any suggestions or corrections.

Ty,
Mark

application details:
cd to your fengoffice root and
sudo patch -p1 --dry-run < /path/to/vcard.patch  (and if no errors show...)
sudo patch -p1 < /path/to/vcard.patch

to remove: sudo patch -R -p1 < /path/to/vcard.patch

39
From what I can find...

vcard 2.1
http://www.imc.org/pdi/vcard-21.txt

vcard 3.0
http://www.ietf.org/rfc/rfc2425.txt
http://www.ietf.org/rfc/rfc2426.txt

1. The current build_vcard function in ./application/controllers/ContactController.class.php inserts a parameter for the charset into many of the fields. According to RFC2426:
Quote
The [VCARD] CHARSET type parameter has been eliminated. Character set can only be specified on the CHARSET parameter on the Content-Type MIME header field.

this practice is no longer allowed in the 3.0 spec (and this function is printing 3.0 as its version). So I'm making a patch that takes those out. I don't think that fixes the overall problem, but that's what the spec says. Also I don't think MIME headers really apply to plaintext vcard files and the topic of character sets and encoding predates me a bit so I can only assume the maintainers knew what they were doing in making this change.

2. Another couple excerpts:
rfc2425
Quote
Each attribute defined in the text/directory body MAY have multiple values, if allowed in the definition of the profile in which the attribute is used. The general rule for encoding multi-valued items is to simply create a new content line for each value (including the type name).  However, it should be noted that some value types support encoding multiple values in a single content line by separating the values with a comma ",".  This approach has been taken for several of the content types defined below (date, time, integer, float), for space-saving reasons.

rfc2426
Quote
The text components are separated by the SEMI-COLON character (ASCII decimal 59). Where it makes semantic sense, individual text components can include multiple text values (e.g., a "street" component with multiple lines) separated by the COMMA character (ASCII decimal 44).

I believe these (and other pieces) say that not only are there multiple address fields, but that each field can have multiple lines using commas. You can also apparently put multiple entire ADR records (also works for a few other types) on one line using commas, but there was no mention that I could find of separating the fields themselves with commas. So I'll also change the field delimiters to semi-colons.

The regexs in the import function seem to already expect semi-colons so no change there. They are also looking for the charset though so I'll patch that out.

It's a start. If anyone sees anything I've got wrong please let me know.

Thank you,
Mark

40
On 1.6.1 and 1.6.2 if I go to Administration -> Add User and select Create contact with user data when creating the user, the contact that is created will have the users email address listed for both email1 and email2.

This is because during this code block around line 740 of ../application/functions.php:
Code: [Select]
       $contact = $user->getContact();
        if ($contact instanceof Contact) {
                // update contact data with data entered for this user
                $contact->setCompanyId($user->getCompanyId());
                // make user's email the contact's main email address
                if ($contact->getEmail2() == $user->getEmail()) {
                        $contact->setEmail2($contact->getEmail());
                } else if ($contact->getEmail3() == $user->getEmail()) {
                        $contact->setEmail3($contact->getEmail());
                } else if ($contact->getEmail2() == "") {
                        $contact->setEmail2($contact->getEmail());
                } else {
                        $contact->setEmail3($contact->getEmail());
                }
                $contact->setEmail($user->getEmail());
                $contact->save();
        }

the software is trying to change the order that the addresses are listed so that it can set the contact's address to be the same as the user's address. However, the code fails to check whether the user and contact already have the same address, resulting in Email1 (previously created during the create_user function) getting moved to Email2, and a duplicate Email1 being put in its place.

I believe the patch I've attached resolves the issue by skipping the entire block of code if $contact->getEmail and $user->getEmail are already the same.

As always though...please let me know if I'm over-looking something horribly obvious.

Mark


P.S. I haven't used the patch program much in the past so this may be helpful info... In my own environment, a cd into the root of fengoffice before "patch -p1 < ...path_to_patch_file..." seems to resolve the issue.

41
I have this issue also. In fact...I created a test contact and filled out every field and then exported to vcard.

Importing back in from that 'native' (if you will) vcard also has this issue. The first thing that jumps out at me is that the vcard export function is comma delimiting the address field whereas the import function's regex is looking for semi-colons.

I'll look at some other implementations to see if maybe I'm missing something and then I'll see if I can offer a patch for this.

42
I do not believe this to be causing a bug, and parts of it could be intentional, but it appears to be a copy/paste that wasn't fleshed out.

I'm sure there are bigger problems but I thought I'd make mention of it here...since I found no previous mention when searching for the function names.

In...

 ./application/models/contacts/Contact.class.php

getFullOtherAddress's comment says that is gets the full work address,

/**
         * Returns the full work address
         *
         * @return string
         */
        function getFullOtherAddress()
        {
                $line1 = $this->getOAddress();


getFullHomeAddress has no comment over it at all.

Also, even though these functions (I'm assuming) are the same except for the type of address they are retrieving, they differ in how they initialize some of their lines.

43
How To's / Re: Adding fields to Contact objects
« on: March 24, 2010, 12:45:05 pm »
Well, the lack of input is a little daunting...but so far this is going well.

Almost all of the work including getters and setters, mysql additions, etc is as simple as adding code for a second and third line wherever you see h_address and w_address and etc.

I have also added this line to the previous list of places that need editing:
/usr/share/fengoffice/language/en_us/general.php:    'address2' => 'Address 2',

...which, that lang entry is actually used for companies...but the original 'address' one seems to be in use for both contacts and companies so I'm adding an address3 and letting contacts and companies use them. I might even go back later and actually add the third line to the companies object.

The rest of the work consists of places where fields are statically mapped like I mentioned with places that have $addr[0]. Most of the code I've found for this so far seems to be related to the vcard import and export. Much to my delight the vcard spec allows for three (or maybe four...I need to re-read it) lines of address info, so I don't think I will have much left to do once I update the regex and field mapping for import and the print statements for export.

44
Development / Re: Ldap Authentication patch
« on: March 18, 2010, 06:55:38 pm »
Remember if you need to use local users in addition to ldap users modify ./application/controllers/AccessController.class.php to look like this:
Code: [Select]
    $userIsValidPassword = $user->isValidPasswordLdap($username, $password, $config_ldap);
                        if (!$userIsValidPassword) {
                          $userIsValidPassword = $user->isValidPassword($password);
                        }
                        } else {
                          $userIsValidPassword = $user->isValidPassword($password);
                        }

Source-> http://forums.fengoffice.com/index.php?topic=2821.0 <- post. The other patch there is something about fixing a typo in the search functions but I don't use that part and have never had a problem.

Also, since I've never seen it mentioned elsewhere...if you're trying to use the 1.5 ldap patch on 1.6.1 and have trouble, you may need to put function hasMailAccounts() and function hasEmailAccounts() back into ../application/models/users/User.class.php after applying the 1.5 ldap patch. As far as I can tell they were new in 1.6.1 and so (of course) are missing from the 1.5 version of the ldap patch.

45
How To's / Adding fields to Contact objects
« on: March 17, 2010, 05:07:50 pm »
Hello,

I'm trying to add a second and third line to each address of my contact objects (e.g. w_address2, h_address3).

Based on comments on this thread -> http://forums.fengoffice.com/index.php?topic=619.0 I have added my fields to the mysql db, added them to the columns array, added getters and setters based on existing fields, and now I'm looking for errata. I just don't think adding a few lines to print functions is going to do it in this case.

Through a series of piped greps I've got the list of files that mention w_address (excluding other languages, for now):
Code: [Select]
/usr/share/fengoffice/language/en_us/fields.php:        'field Contacts w_address' => 'Work address',
/usr/share/fengoffice/language/en_us/project_interface.php:     'field w_address' => 'Work address',
/usr/share/fengoffice/public/install/installation/templates/sql/mysql_schema.php:       `w_address` varchar(200) <?php echo $default_collation ?> default NULL,
/usr/share/fengoffice/application/views/contact/edit_contact.php:                                       <td><?php echo text_field('contact[w_address]'array_var($contact_data'w_address'), array('id' => $genid.'profileFormWAddress''tabindex' => '75''maxlength' => 200)) ?></td>
/usr/share/fengoffice/application/controllers/ContactController.class.php:                      'w_address'=> $contact->getWAddress(),
/usr/share/fengoffice/application/controllers/ContactController.class.php:              $comp['address'] = array_var($contact_data, 'w_address');
/usr/share/fengoffice/application/controllers/ContactController.class.php:              if (isset($checked['w_address']) && $checked['w_address']) $contact_data['w_address'] = array_var($fields, $position['w_address']);
/usr/share/fengoffice/application/controllers/ContactController.class.php:              if (isset($checked['w_address']) && $checked['w_address'] == 'checked') $str .= self::build_csv_field($contact->getWAddress());
/usr/share/fengoffice/application/controllers/ContactController.class.php:                    $block_data["w_address"] = $addr[0];
/usr/share/fengoffice/application/models/contacts/Contacts.class.php:                   'contact[w_address]' => lang('address'),
/usr/share/fengoffice/application/models/contacts/Contact.class.php:    protected $searchable_columns = array('email', 'email2', 'email3', 'firstname', 'w_address', 'h_address', 'o_address');
/usr/share/fengoffice/application/models/contacts/Contact.class.php:            'w_address' => array('w_address', 'w_city', 'w_state', 'w_zipcode', 'w_country'),
/usr/share/fengoffice/application/models/contacts/Contact.class.php:            } else if($column_name == 'w_address') {
/usr/share/fengoffice/application/models/contacts/base/BaseContacts.class.php:     'w_address' => DATA_TYPE_STRING,
/usr/share/fengoffice/application/models/contacts/base/BaseContact.class.php:    * Return value of 'w_address' field
/usr/share/fengoffice/application/models/contacts/base/BaseContact.class.php:      return $this->getColumnValue('w_address');
/usr/share/fengoffice/application/models/contacts/base/BaseContact.class.php:    * Set value of 'w_address' field
/usr/share/fengoffice/application/models/contacts/base/BaseContact.class.php:      return $this->setColumnValue('w_address', $value);

You would think that I could just update them all, such as the 'get all address fields' type functions and it would all be dandy (assuming I'm updating h_address and etc. fields, too). However if you notice...those lines include things like '$addr[0]' which I see has references in:
Code: [Select]
/usr/share/fengoffice/environment/classes/mail/MailUtilities.class.php:                                 $name = $address != trim($addr[0]) ? trim($addr[0]) : "";
/usr/share/fengoffice/environment/classes/mail/MailUtilities.class.php:                                 $address = trim($addr[0]);
/usr/share/fengoffice/application/functions.php:                        if ($addr[0] == '"') {
/usr/share/fengoffice/application/controllers/ContactController.class.php:                    $block_data["h_address"] = $addr[0];
/usr/share/fengoffice/application/controllers/ContactController.class.php:                    $block_data["w_address"] = $addr[0];
/usr/share/fengoffice/application/controllers/ContactController.class.php:                    $block_data["o_address"] = $addr[0];

If someone wants to clarify for me to the last detail what to do that would be fantastic...but more realistically I'm curious if I'm close to the end of the trail or if this 'method' I'm using is going to drag me upside down through the source for the next two weeks.  ;D

Pages: 1 2 [3] 4