PEAR is discontinued

This is a static archive preserving historical releases and metadata. No new packages or updates will be published. For updates to existing packages, or to publish new packages, please use Composer and Packagist.

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.