New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify preferred email addresses and phone numbers #25

Closed
pigmonkey opened this Issue Apr 12, 2013 · 2 comments

Comments

Projects
None yet
2 participants
@pigmonkey
Contributor

pigmonkey commented Apr 12, 2013

The vCard specification includes a PREF type that can be added to email and phone entries to specify the preferred address or number. It would be great if ppl could support this.

If a phone has the PREF type, ppl could put it at the top of the list of phone numbers in the output of ppl show .... Or perhaps ppl should prepend a special character to it, such as *.

If an email has the PREF type, ppl should display it in </> next to the contact's name in the output of ppl show ..., as well as being ordered or displayed in the list of email addresses the same as the preferred phone number is displayed in its list.

The preferred email could be specified like this:

$ ppl email jdoe --preferred john@doe.com

This would check if the email john@doe.com already exists for jdoe. If it does, it would set its type to PREF (and remove the PREF type from any other emails, if it exists). If it does not exist, it would add the email and set the type to PREF. The same behaviour could be used for adding or specifying the preferred phone number.

@hnrysmth

This comment has been minimized.

Show comment
Hide comment
@hnrysmth

hnrysmth Apr 13, 2013

Owner

What I like about this and issue #24 is that they are things that were features of an early prototype version of ppl that I decided not to bother with until other priorities were sorted out. There's even an old Ppl::Entity::Email class with a preferred attribute from when this existed.

So yeah, both of these are definitely going to happen. Just a question of when. Now that I know somebody other than me thinks it'd be useful too, I might as well build them in the near future.

Owner

hnrysmth commented Apr 13, 2013

What I like about this and issue #24 is that they are things that were features of an early prototype version of ppl that I decided not to bother with until other priorities were sorted out. There's even an old Ppl::Entity::Email class with a preferred attribute from when this existed.

So yeah, both of these are definitely going to happen. Just a question of when. Now that I know somebody other than me thinks it'd be useful too, I might as well build them in the near future.

@ghost ghost assigned hnrysmth Apr 13, 2013

@hnrysmth

This comment has been minimized.

Show comment
Hide comment
@hnrysmth

hnrysmth Apr 23, 2013

Owner

Damn, this was a surprisingly large amount of refactoring. I guess that's the difference between "array of strings attached to contact" and "entity with its own properties which can be updated independently", which is the transition email addresses and phone numbers had to go through.

Anyway, it's in 1.24.0.

Owner

hnrysmth commented Apr 23, 2013

Damn, this was a surprisingly large amount of refactoring. I guess that's the difference between "array of strings attached to contact" and "entity with its own properties which can be updated independently", which is the transition email addresses and phone numbers had to go through.

Anyway, it's in 1.24.0.

@hnrysmth hnrysmth closed this Apr 23, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment