Feature Request - support for custom fields?

Charles
2009-03-13
2013-01-23
  • Charles

    Charles - 2009-03-13

    Sometimes there are things that could be accomplished by simply adding a new/custom field/column to a table...

    For example, I'd like to see a new column for setting a flag for what type of access a user has: smtp, pop, imap, all, none... as the admin, I could simply add a new field/column in the user table and set up my own rule (requiring no code, I just do this locally in my documentation), ie:

    0-none, 1=all, smtp=2, pop=3, imap=4

    Then, if I wanted a user to have only smtp and pop access, I could simply enter 2,3 into this field, and configure my SQL query accordingly...

    But instead of asking for this as an official custom field, maybe this could be done another way...

    How hard would it be to add some simple code that allows postfixadmin Admins to add new/custom fields to tables? These could then be used in whatever manner the admin wanted (ie, the custom flag for per user access above)...

    The only real issues I see are displaying the fields in the GUI, and upgrades...

    It probably would be fairly easy for the upgrade script to preserve the custom fields/columns and their contents (of course, as a non-coder, I could be way off base here)...

    Displaying the fields in the GUI may be a bit more complex... ie, there'd probably need to be a way to tell postfixadmin what pages they need to display on, and where/how...

    Anyway, is this way out in left field? I'm really just thinking out loud...

     
    • GingerDog

      GingerDog - 2009-03-13

      There's no reason why we couldn't have a 'custom_1' and e.g. 'custom_2' in the mailbox table - and just display their contents as raw text within the UI. Then all that is left to do would be to add config.inc.php variables to enable their presence within the UI.

       
      • Charles

        Charles - 2009-03-13

        I guess thats one way, but what if someone needed more than 2?

        ;)

        I was just trying to think of a generic way to add support ahead of time for stuff that someone might need, without them having to ask for it later.

        2 would definitely be better than none though... :)

         
    • GingerDog

      GingerDog - 2009-03-13

      Well, you could potentially have an arbitrary number of fields - but it would make the interface somewhat more complex (presumably you'd want a 'page' somewhere which would allow you to create/manage those extra fields?).

      Most apps I've seen tend to take the easy way out with this problem and just define a number of custom_N (where N is between 1 and ~6) rather than doing a few database joins to allow for an (effectively) unlimited number of custom fields.

      I don't particularly care either way, but I think it would be easiest to support if we just had e.g. custom_1, custom_2, custom_3 with appropriate entries in config.inc.php to enable them and apply a human readable label to them.

      e.g.
      $CONF['custom_1_enable'] = 'YES';
      $CONF['custom_1_label'] = 'Access type (POP3/IMAP etc)';
      $CONF['custom_2_enable'] = 'YES';
      $CONF['custom_2_label'] = 'Web mail access (YES/NO)';
      $CONF['custom_3_enable'] = 'NO';
      $CONF['custom_3_label'] = '';

       
    • Charles

      Charles - 2009-03-13

      Ok, that sounds really reasonable... and honestly, I imagine that 3 custom fields would probably be more than enough for 95+% of the people who would even want to use them at all...

      Thanks for considering it!

       
    • GingerDog

      GingerDog - 2009-03-13

      there's an entry int he feature requests thing for it.

       
    • Christian Boltz

      Christian Boltz - 2009-03-14

      You can do this easily for fetchmail entries by editing the $fm_struct array and creating the field in the database.

      For all other tables things are more difficult because their code is more difficult for historical reasons.

      I have refactoring all files to somewhat similar to fetchmail.php (or even more optimized) on my to-do list, but I can't promise any timeframe. (I won't complain if someone is faster ;-)

      Once this refactoring is done, I can imagine having a hook/function in config.inc.php which allows to modify the field list for all tables.

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks