Loading ...
Sorry, an error occurred while loading the content.

Field level security !

Expand Messages
  • vishnuvardhan reddy
    Hi! Friends, I would like to know how to implement the security aspect upto field level in magic. Basic requirement for me is , i need to display all the
    Message 1 of 6 , Dec 1, 2001
    • 0 Attachment
      Hi! Friends,
      I would like to know how to implement the
      security aspect upto field level in magic.

      Basic requirement for me is , i need to display all
      the database fields which we have in the tables to
      end-user. So finally ADMIN person will decide the
      read/write option for each & every field to the users.

      So could you have any idea how to implement this
      feature in magic GUI/WEB applications.

      Ultimately what i know is we need to for maintaining
      the database to implement this security.

      But i would like to know the better ideas.

      Thank u,

      Regards
      vishnu.




      ________________________________________________________________________
      For Stock Quotes, Finance News, Insurance, Tax Planners, Mutual Funds...
      Visit http://in.finance.yahoo.com/
    • Craig Martin
      ... At the application level, in GUI and if you re using the Magic Authorization system, use RIGHTS() as expression for the field s enabled or visible
      Message 2 of 6 , Dec 1, 2001
      • 0 Attachment
        > I would like to know how to implement the
        > security aspect upto field level in magic.
        > Basic requirement for me is , i need to display all
        > the database fields which we have in the tables to
        > end-user. So finally ADMIN person will decide the
        > read/write option for each & every field to the users.
        >
        > So could you have any idea how to implement this
        > feature in magic GUI/WEB applications.

        At the application level, in GUI and if you're using the Magic Authorization
        system,
        use RIGHTS() as expression for the field's enabled or visible
        attribute. I doubt you really need to do this for each and every field
        and certainly guess you can abstract it to a number of groups
        to which you can make your users belong.

        In web, same strategy but you'd be best building your own
        table of rights, users and groups and use a simple
        cookie mechanism to have your page merges include or
        exclude and make fields display or editable accordingly.
        No cheap trick to this.

        Craig

        "A _poop_ question, sir?
        Can't I talk about the warp reactor or the transporter?"
      • vishnuvardhan reddy
        Yes, Craig, the onw which u r saying for GUI is i know but for the end-user, he wants all the fields to be display on the screen & he will assign the
        Message 3 of 6 , Dec 1, 2001
        • 0 Attachment
          Yes, Craig, the onw which u r saying for GUI is i know
          but for the end-user, he wants all the fields to be
          display on the screen & he will assign the read/write
          option according to the users.
          See what ultimately they need , at any time they need
          to alter the read/write options. but what u r saying
          is i understood. So ultimately we need to create those
          many groups naaa...........

          vishnu.

          --- Craig Martin <craig@...> wrote: > >
          I would like to know how to implement
          > the
          > > security aspect upto field level in magic.
          > > Basic requirement for me is , i need to display
          > all
          > > the database fields which we have in the tables to
          > > end-user. So finally ADMIN person will decide the
          > > read/write option for each & every field to the
          > users.
          > >
          > > So could you have any idea how to implement this
          > > feature in magic GUI/WEB applications.
          >
          > At the application level, in GUI and if you're using
          > the Magic Authorization
          > system,
          > use RIGHTS() as expression for the field's enabled
          > or visible
          > attribute. I doubt you really need to do this for
          > each and every field
          > and certainly guess you can abstract it to a number
          > of groups
          > to which you can make your users belong.
          >
          > In web, same strategy but you'd be best building
          > your own
          > table of rights, users and groups and use a simple
          > cookie mechanism to have your page merges include or
          > exclude and make fields display or editable
          > accordingly.
          > No cheap trick to this.
          >
          > Craig
          >
          > "A _poop_ question, sir?
          > Can't I talk about the warp reactor or the
          > transporter?"
          >
          >
          >
          >
          > Your use of Yahoo! Groups is subject to
          > http://docs.yahoo.com/info/terms/
          >
          >

          ________________________________________________________________________
          For Stock Quotes, Finance News, Insurance, Tax Planners, Mutual Funds...
          Visit http://in.finance.yahoo.com/
        • Craig Martin
          Tough luck. Okay, maybe you need the flexibility of building your own authorization system... but I think it ll be a bit of a white elephant in that you
          Message 4 of 6 , Dec 1, 2001
          • 0 Attachment
            Tough luck.
            Okay, maybe you need the flexibility of building your own
            authorization system... but I think it'll be a bit of
            a "white elephant" in that you could build it
            and then see it either not used or about <2%
            of it used. Have another go at convincing your user
            they'll never use something so sophisticated
            and a few rights and groups will suffice :)

            Craig

            "Cause I've got faith of the heart,
            I'm going where my heart will take me"



            > but for the end-user, he wants all the fields to be
            > display on the screen & he will assign the read/write
            > option according to the users.
            > See what ultimately they need , at any time they need
            > to alter the read/write options. but what u r saying
            > is i understood. So ultimately we need to create those
            > many groups naaa...........
            > vishnu.
          • Steve Burrows
            Couldnt agree more. The chances of your user sitting down and applying hundreds of rights for each new user that joins the company is remote. What your user
            Message 5 of 6 , Dec 1, 2001
            • 0 Attachment
              Couldnt agree more.
              The chances of your user sitting down and applying hundreds of rights for
              each new user that joins the company is remote.
              What your user wants is fantastic in theory, but compared to the development
              costs and more importantly ongoing costs, its just not practical. I have
              seen this as a requirement in at least 3 big projects, I have never seen it
              implemented (or even developed).

              My attitude to rights is to have one for each physical task that needs
              doing, then lump them together into groups, a group for each job, then give
              each user groups according to the jobs they do.
              The people who have to set up user rights can handle that quickly and
              without a great deal of thought.

              -----Original Message-----
              From: Craig Martin [mailto:craig@...]
              Sent: Saturday, December 01, 2001 11:36 AM
              To: magicu-l@yahoogroups.com
              Subject: Re: [magicu-l] Field level security !

              Tough luck.
              Okay, maybe you need the flexibility of building your own
              authorization system... but I think it'll be a bit of
              a "white elephant" in that you could build it
              and then see it either not used or about <2%
              of it used. Have another go at convincing your user
              they'll never use something so sophisticated
              and a few rights and groups will suffice :)

              Craig

              "Cause I've got faith of the heart,
              I'm going where my heart will take me"



              > but for the end-user, he wants all the fields to be
              > display on the screen & he will assign the read/write
              > option according to the users.
              > See what ultimately they need , at any time they need
              > to alter the read/write options. but what u r saying
              > is i understood. So ultimately we need to create those
              > many groups naaa...........
              > vishnu.





              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            Your message has been successfully submitted and would be delivered to recipients shortly.