1. Mutiple additions are allowed to the DB. I need it to allow only 1 addition per user.
2. View own works fine (directly shows own record)
3. Modify own brings up the search page (I need this to also directly show own record).

I list below the settings you should need to help me:
ID=>[0,'numer',5,8,1,'',''],
Userid=>[7,'alpha',-2,15,0,'',''],
$db_key='ID';
@auth_default_permissions=(0,0,0,0,0);
@auth_signup_permissions=(1,1,0,1,0);
$auth_modify_own=1;
$auth_view_own=1;
$auth_user_field=7;

Please tell me where I'm going wrong!

Thanks.

 
Look at SirDaniel's thread "Can't Modify/delete records" -- the fourth message down. While I haven't tested the code explicitly, I use something similar on my site and it works just fine.


It occurred to me that another way to go about this would be to change permissions when a user firsts adds a record -- maybe a shortened version of the admin_display subroutine that would be called at the beginning of sub html_add_success. If the user no longer had permission to add, the "Add" link wouldn't even show up in the footer menu.

I'll have to think about it for a bit and see if I can figure out how to do it. Can anybody think of a reason this wouldn't work?




------------------
JPD

 
Another way to achieve this is to use the userid as the key. Then if a user tries to add another record, he will get a "duplicate key error". You should of course change the text in db.cgi to something more descriptive.

Make sure you are using 2.04, and set $db_track_key = 0.

Hope this helps,

Alex

And for those of you who are curious if it I ever did get it to work... The answer is YES!!!

This is how:

In the .cfg file, I defined a new set of permissions which are the new ones to be used after a user has successfully added his/her record. Like so:

@new_user_permissions = (1,0,0,1,0);

In the .cgi file, under the subroutine add_record, I added:

BETWEEN

if ($status eq "ok") {
open (DB, ">>$db_file_name") or &cgierr("error in add_record. unable to open database: $db_file_name.\nReason: $!");
if ($db_use_flock) {
flock(DB, 2) or &cgierr("unable to get exclusive lock on $db_file_name.\nReason: $!");
}
print DB &join_encode(%in);
close DB;

AND

if ($db_key_track) {
open (ID, ">$db_id_file_name") or &cgierr("error in get_defaults. unable to open id file: $db_id_file_name.\nReason: $!");
if ($db_use_flock) {
flock(ID, 2) or &cgierr("unable to get exclusive lock on $db_id_file_name.\nReason: $!");
}
print ID $in{$db_key};
close ID;
}

THIS:

open (PASS, "<$auth_pw_file") or &cgierr ("unable to open: $auth_pw_file.\nReason: $!");
if ($db_use_flock) { flock(PASS, 1) }
@lines = <PASS>;
close PASS;
open (PASS, ">$auth_pw_file") or &cgierr ("unable to open: $auth_pw_file.\nReason: $!");
if ($db_use_flock) {
flock(PASS, 2) or &cgierr("unable to get exclusive lock on $auth_pw_file.\nReason: $!");
}
my $fuck = 0;
foreach $line (@lines) {
($line =~ /^$db_userid:/) ?
($fuck = 1) :
print PASS $line;
@cstepassword = (split (/:/, $line))[1];
@cstepermissions = join (":", @existing_user_permissions);
}
close PASS;

open (PASS, ">>$auth_pw_file") or &cgierr ("unable to open: $auth_pw_file.\nReason: $!");
if ($db_use_flock) {
flock(PASS, 2) or &cgierr("unable to get exclusive lock on $auth_pw_file.\nReason: $!");
}
print PASS "$db_userid:@cstepassword:@cstepermissions\n";
close PASS;

END

And now for something totally different

Hope this helps any existing/new users of DBMan.

Thanks again to all who helped me!


Chris.

JPDeni: Thank you for referring me to the other posting. It solved the modify own problem. Clicking on modify in usermode directly shows own record whereas in admin mode, gives you the search form. This problem solved.

However, I still have the problem with the add record. (Alex: I need the autoincrement of the ID field)

I have understood what you were trying to say about changing the user permissions in the sub add_success and was wondering if this would help anyone figure out how it can be done:

sub add_success {
&change_permissions
.
.
}

sub change_permission {
OPEN THE PASSWORD FILE
FIND THE MATCHING USER
ASSIGN THE USERNAME & PASSWORD TO VARIABLES
DELETE THE USER
REWRITE USER FROM VARIABLES + NEW PERMISSIONS
CLOSE THE PASSWORD FILE
}

Hope this inspires someone. It may not be necessary to delete user then re-write if there is a way to replace an entry.


Thanks is advance,

Chris.

 
Kewl! I was hoping that would work. Glad I could help.


Part of sub admin_display in db.cgi allows the admin to change the permissions for a user -- I think without deleting the user first, although I may be wrong. I think your sub change_permission would just need to be that part of admin_display, with probably a few other minor changes. I'm just not sure about some of the Perl commands that subroutine uses, so I'm hesitant to mess around with it.





------------------
JPD

Hmmm... risked it and played with the db.cgi routines for modifying a user's permissions but without success.
It remains the best workaround to my problem.
Can ANYONE do it?

As a sub sub-routine for sub add_success:

OPEN AUTH.PL
FIND CURRENT USER
REPLACE PERMISSIONS WITH 1:0:0:1:0
CLOSE AUTH.PL

Thanks in advance (Alex...HELP... hehehe)

Chris.

I've thought about it a bit, and I think the following should work.

-------------------------
In html.pl -- sub html_add_success, before &html_print headers, add

$per_add = 0;
&change_permissions;

In db.cgi, at the end, add

sub change_permissions {
open (PASS, "<$auth_pw_file") or &cgierr ("unable to open: $auth_pw_file.\nReason: $!");
if ($db_use_flock) { flock(PASS, 1); } @lines = <PASS>;
close PASS;
open (PASS, ">$auth_pw_file") or &cgierr ("unable to open: $auth_pw_file.\nReason: $!");
if ($db_use_flock) {
flock(PASS, 2) or &cgierr("unable to get exclusive lock on $auth_pw_file.\nReason: $!");
}
foreach $line (@lines) {
if ($line =~ /^$db_userid:/) {
my $password = (split (/:/, $line))[1];
print PASS "$db_userid:$password:$per_view:$per_add:$per_del:$per_mod:$per_admin\n";
}
else {
print PASS $line;
}
}
}

-----------------------

Having said that, it occurred to me that you might run into some problems if your user deletes his record. He won't be able to add a new one. There are a couple of ways to go with this.

If registered users do not have to have a record in the database -- which would only make sense if you require a logon to view other people's records -- add the following:

-------------------
In html.pl -- sub add_success, after the lines you added above, add

$per_del = 1;

In html.pl -- sub delete_success, before &html_print_headers

add

$per_del = 0;
$per_add = 1;
&change_permissions;

--------------------------

If you allow a default user to view records or users can only view their own records, there's no point in keeping the user's login info in your password file. You would probably want to add something to sub html_delete_form that would tell the user if he deletes his record he will be removed from the system, but he is still welcome to view the records and is invited to signup again whenever he wants.

You can put the following code in a subroutine if you want, but since it will only be used here, you might as well add it directly to sub html_delete_success.

Before &html_print_headers;
add

------------------------
open (PASS, "<$auth_pw_file") or &cgierr ("unable to open: $auth_pw_file.\nReason: $!");
if ($db_use_flock) { flock(PASS, 1) }
@lines = <PASS>;
close PASS;
open (PASS, ">$auth_pw_file") or &cgierr ("unable to open: $auth_pw_file.\nReason: $!");
if ($db_use_flock) {
flock(PASS, 2) or &cgierr("unable to get exclusive lock on $auth_pw_file.\nReason: $!");
}
foreach $line (@lines) {
($line =~ /^$db_userid:/) ?
($found = 1) :
print PASS $line;
}
close PASS;
-------------------------

You would probably then want to add something to html_delete_success saying that the user's record and login information had beed removed from the database and repeat that he is welcome to view records and to signup again whenever he wants -- whatever is appropriate wording for your site.

As with all of the code I've been suggesting to people lately, this is untested. It is just copying other parts of the DBMan code, though, and eliminating a few of the error routines that didn't seem to be necessary. If it doesn't work -- or if it does! -- please let me know.



------------------
JPD


[This message has been edited by JPDeni (edited December 22, 1998).]

[This message has been edited by JPDeni (edited December 22, 1998).]

[This message has been edited by JPDeni (edited December 22, 1998).]

Chris, looks like you got to it before I did! Blame it on 'net lag.

Excellent!!!



------------------
JPD

Errr... Oopth. Please ignore the f*$% word in my previous posting. I forgot to edit it during pasting it here for you ppl to see.

Sowwy

But while I'm here, let me exaplin what I did exactly:

The first opening of the password file, locates the user and assigns the existing password and new permissions to variables. It then deletes the user from the password file altogether.

The second opening of the password file, adds a new user with the $db_userid at hand, the same password and the new permissions from the variables pre-defined.

Easy?


Chris.

Don't anybody use the modification I posted above! In looking over it, I realized that if an admin person deletes a file, his password will be deleted and he won't be able to do admin functions any more!!

I'm working on putting up a some web pages with some of the mods I've put up here. I'll try to test them out before I get them up.



------------------
JPD