PEAR is archived and read-only

This mirror preserves historical PEAR package releases and metadata so existing references remain available.

Home » Authentication » LiveUser » Bug #1131

unnecessary unique key in rights table

Details

Submitted2004-04-05 02:17 UTC
Fromsimon dot hamilton at ntlworld dot com
Assignedlsmith
StatusClosed
PackageLiveUser
PHP VersionIrrelevant
OSn/a
Roadmaps(Not assigned)

Comments

[2004-04-05 02:17 UTC] simon dot hamilton at ntlworld dot com

Description:
------------
In perm_db.sql there is:

UNIQUE KEY `right_define_name` (`right_define_name`)

in the `liveuser_rights` table.

As far as I've been using it without this being unique and having several overlaps I don't see that its necessary to have this in as default.

Since defines in an app are mostly composed with AREA_ or maybe even APP_AREA_ then there is no need for individual rights definenames to be unique. I have for instance:

AREA1_READ
AREA1_WRITE
AREA2_READ
AREA2_WRITE

What do you think?

--
Simon H

[2004-04-05 09:10 UTC] simon dot hamilton at ntlworld dot com

I'd have to say that you should not be relying on unique keys to catch your development errors accidental or not.

Also, I wrote it here rather than the list because I have lost discussions on topics like this (that are important) on the list before. When a bug report is submitted at least it gets a decent reponse.

If we have the ability to create Defines with APP_AREA_RIGHT then we would have:

APP_NEWS_NEWS_WRITE

That could get ugly.

[2004-04-22 14:01 UTC] smith at backendmedia dot com

Ok I have deleted the unique setting. I am not in favor of handling the uniqueness in the export method.

Can someone handle this?

[2004-04-22 16:35 UTC] smith at backendmedia dot com

You are probably right .. this does seem like to way to go .. I had my mind twisted into all sorts of unusual ways.

[2004-05-13 10:34 UTC] smith at backendmedia dot com

This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pear.php.net.

In case this was a pear.php.net website problem, the change will show
up on the website in short time.

Thank you for the report, and for helping us make PEAR better.