Return-Path: X-Original-To: apmail-directory-users-archive@www.apache.org Delivered-To: apmail-directory-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3E16C10755 for ; Wed, 12 Feb 2014 16:20:54 +0000 (UTC) Received: (qmail 7538 invoked by uid 500); 12 Feb 2014 16:20:53 -0000 Delivered-To: apmail-directory-users-archive@directory.apache.org Received: (qmail 7495 invoked by uid 500); 12 Feb 2014 16:20:53 -0000 Mailing-List: contact users-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@directory.apache.org Delivered-To: mailing list users@directory.apache.org Received: (qmail 7487 invoked by uid 99); 12 Feb 2014 16:20:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Feb 2014 16:20:53 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of adavis@verticalsearchworks.com designates 66.150.157.191 as permitted sender) Received: from [66.150.157.191] (HELO mail.verticalsearchworks.com) (66.150.157.191) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Feb 2014 16:20:47 +0000 Received: from CNVR-EXCH01.convera.com ([10.21.0.21]) by cnvr-exch01 ([10.21.0.21]) with mapi; Wed, 12 Feb 2014 08:20:25 -0800 From: Ashton Davis To: "users@directory.apache.org" Date: Wed, 12 Feb 2014 08:20:23 -0800 Subject: Feature Request: AutoIncrement fields Thread-Topic: Feature Request: AutoIncrement fields Thread-Index: Ac8oDIGwJv9SWzuCTqaNG12BUVfh8Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CFA73F1CD063634CB7C435EBBC36BA4B0EC40B6426cnvrexch01_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_CFA73F1CD063634CB7C435EBBC36BA4B0EC40B6426cnvrexch01_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I run my Linux environment authentication from Directory Server, and so I u= se Posix users and groups. As I continue to add users to the system, I'm f= inding it to be an increasing inconvenience to have to find the last UID I = used and increment by one. There are programmatic ways to handle this, but= none of them truly address the issue. What we need is to have Directory S= erver (and Directory Studio) handle incrementing numerical ID fields. There's already an RFC in existence: http://tools.ietf.org/html/rfc4525 Another "nice to have" would be enforcement of unique fields (uidNumber sho= uld be able to be forced unique) Use case: I'm creating a new user for my linux environment. They get created as posixAccount, which requires uidNumber I give them their cn, gidNumber (which is one of two right now), homeDirect= ory, loginShell, etc - nothing out of the ordinary. Then I get to uidNumber. I have to make sure I know what uidNumber was use= d last. Find it. Add one to it. And hope nobody else has added users sin= ce I last did. Solution: Click uidNumber field -> check "auto-increment" and "unique" Once I save the entry, it creates a uidNumber for me and applies it to the = field. I hope that's detailed enough. Ashton Davis Sr. Systems Administrator VerticalSearchWorks 760.930.7690 --_000_CFA73F1CD063634CB7C435EBBC36BA4B0EC40B6426cnvrexch01_--