Password protected access to menu. Advice ?

[Marc Venken]

Hello,

For my online soccer member program, I want to have a password protection for access level.

ex.

There are 5 levels (Admin, Headmember, Submember, trainer, player)

I have a loop that builds btnbmp's for each team (see right) Team are in a database.

Each button will give a scooped team with players.

Code: Select all  Expand view

     @ nTop+nMove,nLeft BTNBMP aBtn[i] OF oDlg SIZE 80, 25 NOBORDER PROMPT aPloegen[i] 2007 ACTION SET_SCOPE_ploegen(oBrw,::cCaption) font oBold CENTER
 

I want only to see the buttons that are allowed :

The admin sees all
But submembers ex. 7 selected teams
trainer : only see 1 selected team (17 diferent trainers)
players : only there personal data (not yet build)

Any advice/Tips before I get into this ?

[cnavarro]

And use clausule WHEN in buttons ?

[Rick Lipkin]

Marc

Like you .. I have roles for each of the users of my applications .. I set PUBLIC charactors (YN) values for each role :


In this case

xRead := "Y"
xWrite := "Y"
xTech := "Y"
xMgr := "Y"
xDisp :="Y"
xSuper := "Y"
xAdmin := "Y'


Since these values are Public .. I can interrogate them at any time :

Code: Select all  Expand view

If xSuper = "Y" .or. xAdmin = "Y"
   // Do something
Else
   oBtn:Hide()  
   Return(.f.)
Endif
 

You can get creative as Cristabol mentions .. build your buttons when xMgr = "Y" and so on...

Hope that helped
Rick Lipkin

[James Bott]

Here is a sample showing how you can eliminate publics. One disadvantage of using publics is that they have to be declared in every routine that uses them or you will get compiler warnings. Of course, since publics are visible everywhere you always run the risk of conflicts with locals and fieldnames--even in code you didn't write such as the language itself.

Code: Select all  Expand view

#include "fivewin.ch"

class TUser
   data name as char
   method new
endclass

method new()
   ::name:=""
return self

function user()
   static oUser
   if oUser == nil
      oUser:= TUser():new()
   endif
return oUser

You can then do:

user():name:= "JBott"

msgInfo(user():name) // returns JBott

 

Regards,
James

[Enrico Maria Giordano]

Here is a sample showing how you can eliminate publics. One disadvantage of using publics is that they have to be declared in every routine that uses them or you will get compiler warnings.

Or you can use them as

Code: Select all  Expand view

M -> varname

This has the advantage that you can easily locate them.

EMG

[James Bott]

Enrico,

This has the advantage that you can easily locate them.

Yes, it is an advantage over using a PUBLIC without the "m->" nomenclature.

However you can easily locate the user object too. Just search for "user()"

You can also add methods to the user object--something you can't do with a PUBLIC. For instance you could keep track of how long a user has been logged in to the program:

MsgInfo( User():logonTime() )

OK, I admit it--I have a passion for objects.

Regards,
James

[Marc Venken]

Thanks for the input.

Rick, I like the idea of a Xbrowse like yours, and folow the idea.

SO, I create a browse with
colums "Team1,Team2,Team3,..."
Rows "Trainer1, Trainer2,Trainer3...."

Trainer 1 J,N,N,N,J
Trainer 2 N,N,N,J,N

A trainer logs into the system, and I retrieve the rows of that trainer and put the coloms into a array (J,N,N,N,J)

Into the loop I have to make a call with the array to show the button or not. (J = Show and N = Not)

I try to work this out.

[Marc Venken]

James,

I'm not ready yet for this. I haven't had the time to look into your info on your site

I can work with the database like
function(oDbf)

? oDbf:Naam
? oDbf:Street
...
and oDbf:save() ...

But with Method like your sample. To early I can't see the logic.

[James Bott]

Marc,

To early I can't see the logic.

Are you familiar with STATICs?

This is just using a static variable inside a function to hold an object. The reason for doing this is because the static will hold the object until the program is ended. So, you can access the object anywhere without even declaring it.

You have the code above, just try it. A few minutes spent now learning about objects will save you tremendous time later. I have converted traditional code to objects sometimes reducing code by 50%! This makes it much easier to read and understand for several reasons. One there is less code to read, it is self explanatory, and encapsulation makes it much more stable.

Regards,
James

[Marc Venken]

James,

In the Class we put all the items we think we need :

data bird as date
data tva as char
data counter as num

in the method new we set the defaults ?

:: name:=""
:: bird:=ctod("26/11/1985")
:: tva:= "blabla"
:: counter:= 1

but also from from datasource ?

:: bird:= customer->bird
:: counter:= customer->number

or only later with

user():name:= "JBott"
or
user():name:= alltrim(customer->name)

Functions User() will create the object as static to see all over the program

[James Bott]

Marc,

Yes for most of what you said.

Functions User() will create the object as static to see all over the program

And yes, for the above, however this is a special case like for user. Normally you declare and create the object in the routine and use it just like a local. However, an object can contain its own methods and an object can be passed to another routine, that routine can change data of the object and you DON'T have to return the object.

Code: Select all  Expand view

oItem:color:="Red"
ChangeColor( oItem )
MsgInfo( oItem:color ) // returns "Blue"

Function ChangeColor( oItem )
   oItem:color:="Blue"
Return nil
 

The only reason I use a function containing a static is for the special case of user so I don't have to declare it in every routine that I use it. This is a unique case and the only instance I have found this useful, so don't get confused about this having much to do with learning OOP. That said, it is very useful for a user object--not only can you store their permissions, but also any user preferences, and then you can access them easily anywhere. This also has allowed me to eliminate the use of PUBLICs anywhere in my programs. I used to get name conflicts with PUBLICs that created bugs that were very hard to find. No more.

Regards,
James

[Enrico Maria Giordano]

Here is a sample showing how you can eliminate publics. One disadvantage of using publics is that they have to be declared in every routine that uses them or you will get compiler warnings. Of course, since publics are visible everywhere you always run the risk of conflicts with locals and fieldnames--even in code you didn't write such as the language itself.

Code: Select all  Expand view

#include "fivewin.ch"

class TUser
   data name as char
   method new
endclass

method new()
   ::name:=""
return self

function user()
   static oUser
   if oUser == nil
      oUser:= TUser():new()
   endif
return oUser

You can then do:

user():name:= "JBott"

msgInfo(user():name) // returns JBott

 

Regards,
James

If I well understood what you want to get, isn't this better?

Code: Select all  Expand view

#include "fivewin.ch"


function main()

    TUser():name:= "JBott"

    msgInfo(TUser():name)

    return nil


class TUser
   classdata name as char
endclass

EMG

[TimStone]

My system is very simple, and has been used for over 20 years without a problem.

The administrator has access to a setup screen. There he can issue user names and passwords and for each user there are about 25 program areas he can check to grant access. These are saved in an encrypted database.

When a user logs into the program, his "rights" are checked, and saved as logicals in one public array.

All menu items only display if the user has rights. Thus they never see what they can't access.

This is a very easy setup. It just never fails !

Tim

[Marc Venken]

My system is very simple, and has been used for over 20 years without a problem.

The administrator has access to a setup screen. There he can issue user names and passwords and for each user there are about 25 program areas he can check to grant access. These are saved in an encrypted database.

When a user logs into the program, his "rights" are checked, and saved as logicals in one public array.

All menu items only display if the user has rights. Thus they never see what they can't access.

This is a very easy setup. It just never fails !

Tim

This is like Rik above, but only you put the rights into a array.

I could make a Xbrowse like Rik, and even have all options/rights as chexkboxes in the Xbrowse. Then I don't need to create/update a dialog.

[Marc Venken]

James,

In Your way the folowing can be easily done ?

In this button, from a Xbrowse action :

@ 60, 111 BTNBMP PROMPT "Save" OF oDlg SIZE 42, 14 PIXEL FLAT ;
WHEN oRec:Modified() ;
ACTION If( oRec:Save(), oDlg:End(), nil )

The oRec is a object containing all data and the oRec:save() will excecute when something has changed.

Now I would like a new behavior :

When oRec:save() executes, I also want this to happen ex. change the update field in the database with the current date : oRec:update=date() and then save.

Purpose : When a record is changed, I would like to know the update date.

Later on, I finaly would like a kind of update tracking :

Does oRec have a kind of flag for every changed item/field into it ? Say that the name and street are only changed
I would like to save that into a log file like :

id, name, updatedate, changed items (Name, street) maybe even (oldname = newname, oldstreet = newstreet)