Home » Authentication » LiveUser » Bug #1131
unnecessary unique key in rights table
Details
| Submitted | 2004-04-05 02:17 UTC |
|---|---|
| From | simon dot hamilton at ntlworld dot com |
| Assigned | lsmith |
| Status | Closed |
| Package | LiveUser |
| PHP Version | Irrelevant |
| OS | n/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.