Menu
▾
▴
slashcode-development
|
From: Alvaro d. C. <ac...@ba...> - 2001-03-10 07:32:27
|
Hi! Yesterday I found that a list about slashcode development exists. ¡Great! My name is Alvaro del Castillo and I work for BarraPunto.com a Spanish weblog about free software and many other things ;-) Yes, it is based in slashcode ;-) I have worked in slashcode for the last 4 months and I think I know it in some depth. As many of other users of slashcode we have modified it in several ways and now we are migrating all our new code to Bender. Bender is a great advance. It has a solid architecture. After some time exploring it, we have migrated our new code to Bender without breaking the clean architecture scheme. Our main success has been to introduce an ACL scheme in Bender. We need it because we have modified the software so each registered user can have its own section and we have to give it the admin interface in a controled way. I think that our ACL scheme could be a great tool for slashcode and I hope to send you a patch so you can check it. I have worked in 1.1.4 so when I download 1.1.5 and migrates the changes, I will send the patch. Also, I am writing a doc about Bender architeture. Some Dia diagrams and some text describing the architectura. Is there any doc yet about Bender architetcure? Greetings and happy hacking -- Alvaro =================================================== Alvaro del Castillo San Félix ac...@ba... Barrapunto.com |
|
From: Brian A. <br...@ta...> - 2001-03-10 07:47:42
|
Alvaro del Castillo wrote: > Our main success has been to introduce an ACL scheme in Bender. We need > it because we have modified the software so each registered user can > have its own section and we have to give it the admin interface in a > controled way. Can you expllain how your ACL's work? > Also, I am writing a doc about Bender architeture. Some Dia diagrams and > some text describing the architectura. Is there any doc yet about Bender > architetcure? I am working on such a beast and one should exist by monday. -Brian -- _______________________________________________________ Brian Aker, br...@ta... Slashdot Senior Developer Seattle, Washington http://tangent.org/~brian/ http://slashdot.org/ _______________________________________________________ You can't grep a dead tree. |
|
From: Alvaro d. C. <ac...@ba...> - 2001-03-10 08:15:24
|
Brian Aker wrote:
>
> Alvaro del Castillo wrote:
> > Our main success has been to introduce an ACL scheme in Bender. We need
> > it because we have modified the software so each registered user can
> > have its own section and we have to give it the admin interface in a
> > controled way.
> Can you expllain how your ACL's work?
It's very simple:
We have created a new table users_acl
mysql> desc users_acl;
+-----------------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------+---------+------+-----+---------+-------+
| uid | int(11) | | PRI | 0 | |
| op_insert_index | text | YES | | NULL | |
| op_delete_index | text | YES | | NULL | |
| op_admin_index | text | YES | | NULL | |
+-----------------+---------+------+-----+---------+-------+
At the moment we only need to control this three operations, but the
scheme can be expanded easily.
When a user reach the site, in the users object we also put the ACLs. So
in $user->{op_insert_index} appear all the sections in which the user
can
insert stories. An so on with the other operations.
For example:
mysql> select op_insert_index from users_acl where uid=45;
+--------------------------------------------------------------------------------------------------------------------------------+
|
op_insert_index
|
+--------------------------------------------------------------------------------------------------------------------------------+
|
'mbp-acs','index','kde','gnome','mbp-rodrigo','solo-es','solo-mx','mbp-esteve','empresas','boinapunto','mbp-giordino','debian'
|
+--------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
If we want to create a new ACL that control if a user can insert polls
in
a section, it's easy. We modify the table and add a new column with the
new
operation.
The functions that controls if a user has a correct ACL are independant
of the number of operations that appear in that table.
This functions are:
getACLindex ($op,$index)
removeACLindex($uid,$op,$op_indexes) (it works for several indexes)
saveACLindex($uid,$op,$op_indexes) (it works for several indexes)
The getACLindex don't touch the database because all the information
that it needs is the $user object.
For example, if you want to let the user use admin.pl in a ACL way:
admin.pl (1.09):
...
if (($op eq 'edit')&&(getACLindex("op_insert_index","*"))) {
editstory($I{F}{sid});
With $index value equal "*" getACLindex returns true if the user can
insert
stories in some index.
In our site we have the two schemes, ACLs and seclev, working together
but
we plan to migrate everything to the ACLs scheme. The migration from
one scheme to the other is not difficult and can be done smoothly.
At the moment, with users_acl we only can control using the section
concept
but it could be easy to expand the model.
The key is that this scheme is integrated with slashcode in a clean way.
We have migrated to bender very easy. Only we have to modify Slash::DB
to
tell getUser and setUser to take the data also from users_acl.
In our site we have developed this idea and we have the concept of
MySlash. An user can has it own "mini-slash site" integrated with
the site. For this we have to make another key change in slashcode
architecture: an story can appear the same in more than one section.
This little change, a new table that relation stories and sections,
has enabled us to build a great stories syndication platform.
I hope I have explain everything clear but maybe, the patch will show
you
the details. It could be great to integrate our work with the main
slashcode root.
Cheers
-- Alvaro
>
> > Also, I am writing a doc about Bender architeture. Some Dia diagrams and
> > some text describing the architectura. Is there any doc yet about Bender
> > architetcure?
> I am working on such a beast and one should exist by monday.
> -Brian
> --
> _______________________________________________________
> Brian Aker, br...@ta...
> Slashdot Senior Developer
> Seattle, Washington
> http://tangent.org/~brian/
> http://slashdot.org/
> _______________________________________________________
> You can't grep a dead tree.
>
> _______________________________________________
> Slashcode-development mailing list
> Sla...@li...
> http://lists.sourceforge.net/lists/listinfo/slashcode-development
--
===================================================
Alvaro del Castillo San Félix ac...@ba...
Barrapunto.com
|
|
From: Chris N. <pu...@po...> - 2001-03-12 13:41:17
|
At 08:26 +0100 2001.03.10, Alvaro del Castillo wrote:
>mysql> desc users_acl;
>+-----------------+---------+------+-----+---------+-------+
>| Field | Type | Null | Key | Default | Extra |
>+-----------------+---------+------+-----+---------+-------+
>| uid | int(11) | | PRI | 0 | |
>| op_insert_index | text | YES | | NULL | |
>| op_delete_index | text | YES | | NULL | |
>| op_admin_index | text | YES | | NULL | |
>+-----------------+---------+------+-----+---------+-------+
>
>
>At the moment we only need to control this three operations, but the
>scheme can be expanded easily.
>
>When a user reach the site, in the users object we also put the ACLs. So
>in $user->{op_insert_index} appear all the sections in which the user
>can
>insert stories. An so on with the other operations.
Yeah, I was thinking about something very similar at one point, and think
this is a nice idea. I wonder, though, if maybe users_param would be a
better user of this? So instead of:
>mysql> select op_insert_index from users_acl where uid=45;
You would have:
select value from users_param where uid = 45 and name = 'op_insert_index';
Or, alternatively, implement users_acl _as_ a param-style table. The
problem, of course, is that we could have dozens of types of permissions,
and it is easier to just insert a new value than it is to change the schema
each time you want to add a new one (and this would make it more easily
extensible via the admin interface, too). Also, a table with a few dozen
fields could be slower and more bloated.
--
Chris Nandor pu...@po... http://pudge.net/
Open Source Development Network pu...@os... http://osdn.com/
|
|
From: Brian A. <br...@ta...> - 2001-03-12 16:54:21
|
Chris Nandor wrote: > Yeah, I was thinking about something very similar at one point, and think > this is a nice idea. I wonder, though, if maybe users_param would be a > better user of this? So instead of: I would keep it out of users_param, but use the same schema. > Or, alternatively, implement users_acl _as_ a param-style table. The > problem, of course, is that we could have dozens of types of permissions, > and it is easier to just insert a new value than it is to change the schema > each time you want to add a new one (and this would make it more easily > extensible via the admin interface, too). Also, a table with a few dozen > fields could be slower and more bloated. The param style table is actually pretty quick for look ups. If the schema was modified to resemble a param table and we had patches for getUser() and setUser() I would probably be all for including it. It might be nice also to have a seperate table which described param's currently in use. -Brian |
|
From: Chris N. <pu...@po...> - 2001-03-12 18:06:28
|
At 09:47 -0800 2001.03.12, Brian Aker wrote: >Chris Nandor wrote: >> Yeah, I was thinking about something very similar at one point, and think >> this is a nice idea. I wonder, though, if maybe users_param would be a >> better user of this? So instead of: >I would keep it out of users_param, but use the same schema. >> Or, alternatively, implement users_acl _as_ a param-style table. The Yeah, I think that would be best. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
|
From: Alvaro d. C. <ac...@ba...> - 2001-03-12 18:22:32
|
Hi! > Yeah, I was thinking about something very similar at one point, and think > this is a nice idea. I wonder, though, if maybe users_param would be a > better user of this? So instead of: > > >mysql> select op_insert_index from users_acl where uid=45; > > You would have: > > select value from users_param where uid = 45 and name = 'op_insert_index'; Yes, i have looked to this table and it is perfect for the use we are doing of users_acl. But the name and value fields must be bigger. A user can have lots of sections in wich it can do some operations. I don't know if when you designed the table you have in mind params so large. > > Or, alternatively, implement users_acl _as_ a param-style table. The > problem, of course, is that we could have dozens of types of permissions, > and it is easier to just insert a new value than it is to change the schema > each time you want to add a new one (and this would make it more easily > extensible via the admin interface, too). Also, a table with a few dozen > fields could be slower and more bloated. Yes, thinking in the users_param table it is more flexible than the actual users_acl which needs to be altered each time a new permissions is created. With the users_param table the things are more flexible and as you say, it makes more easy to create new type of permisssions from the admin interface. At the moment we use the ACLs to control only sections. We create a new section and then, we give ACL op_admin_index to some users. This users then can give the ACLs op_admin_index, op_insert_index or op_delete_index to other users. This "admin" users have the control over the index and they can work on in an independent way from the main editors. Other example is when a user creates her MySlash, it is created automatically a new section for her stories and the user receives the op_admin_index ACL over her new section. Then, the user can works in the section and can give ACLs for other users. ACLs enable a very decentralized way of work so you can give more power to the community. Bye -- Alvaro > > -- > Chris Nandor pu...@po... http://pudge.net/ > Open Source Development Network pu...@os... http://osdn.com/ > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development -- =================================================== Alvaro del Castillo San Félix ac...@ba... Barrapunto.com |
|
From: Chris N. <pu...@po...> - 2001-03-12 18:53:36
|
At 18:02 +0100 2001.03.12, Alvaro del Castillo wrote: >Hi! > >> Yeah, I was thinking about something very similar at one point, and think >> this is a nice idea. I wonder, though, if maybe users_param would be a >> better user of this? So instead of: >> >> >mysql> select op_insert_index from users_acl where uid=45; >> >> You would have: >> >> select value from users_param where uid = 45 and name = 'op_insert_index'; > >Yes, i have looked to this table and it is perfect for the use we are >doing >of users_acl. But the name and value fields must be bigger. A user can >have >lots of sections in wich it can do some operations. I don't know if >when you designed the table you have in mind params so large. Actually, users_param just uses a text field for "value" now. So the only issue would be picking a better limit for "name". At 18:09 +0100 2001.03.12, Alvaro del Castillo wrote: >Do you think that this model could replace the seclev model in >the future? As I say in other email, I have found very easy to make >co-live the to models in the transition. I think so, yes, though there could be something i am not thinking of. Currently we only use seclev for "is anonymous," "is regular user," "is author," "is admin." But this would be replaced by things like "can_unlimited_moderate" etc. in the ACLs. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
|
From: Alvaro d. C. <ac...@ba...> - 2001-03-12 18:29:13
|
Brian Aker wrote: > > Chris Nandor wrote: > > Yeah, I was thinking about something very similar at one point, and think > > this is a nice idea. I wonder, though, if maybe users_param would be a > > better user of this? So instead of: > I would keep it out of users_param, but use the same schema. > > > Or, alternatively, implement users_acl _as_ a param-style table. The > > problem, of course, is that we could have dozens of types of permissions, > > and it is easier to just insert a new value than it is to change the schema > > each time you want to add a new one (and this would make it more easily > > extensible via the admin interface, too). Also, a table with a few dozen > > fields could be slower and more bloated. > The param style table is actually pretty quick for look ups. > > If the schema was modified to resemble a param table and we had patches > for getUser() and setUser() I would probably be all for including it. If we use the users_param table we don't need to touch getUser and setUser, no? The changes are reduced to modify the ACL functions that I have included in Slash.pm. Is it the correct place? This changes are minimal. > > It might be nice also to have a seperate table which described param's > currently in use. Yes, because the kind of operations that a site can have can't be determinated a priori. The ACL scheme enables the creations of new operations without any need to change the actual code. Only when you have to take advantge of this new operations you have to tell it to the getACLindex. Do you think that this model could replace the seclev model in the future? As I say in other email, I have found very easy to make co-live the to models in the transition. I plan to send a patch to the list to show how we have modified admin.pl to partially work using ACLs. Bye -- Alvaro > -Brian > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development -- =================================================== Alvaro del Castillo San Félix ac...@ba... Barrapunto.com |
|
From: Brian A. <br...@ta...> - 2001-03-12 18:44:18
|
Alvaro del Castillo wrote: > If we use the users_param table we don't need to touch getUser and > setUser, > no? True, you could. The only thing that would be left is a table describing the ACL. The only thing I worry about is that users_param is a type of text, which could be slow for very large sites. Which is why you might want to have a separate table. Course, the table is entirely indexed. Just put it in users_param, if it turns out to be a performance issue it will be easy to fix. > The changes are reduced to modify the ACL functions that I have included > in Slash.pm. Is it the correct place? This changes are minimal. Well, the ACL functions should be in Slash::Utility. > the future? As I say in other email, I have found very easy to make > co-live the to models in the transition. We can make the two live side by site at the moment. Long term I would prefer to see only one though (just me), but I don't see it as a priority. > I plan to send a patch to the list to show how we have modified admin.pl > to partially work using ACLs. Cool. -Brian |
|
From: Alvaro d. C. <ac...@ba...> - 2001-03-13 07:43:41
|
Brian Aker wrote: > > Alvaro del Castillo wrote: > > If we use the users_param table we don't need to touch getUser and > > setUser, > > no? > True, you could. The only thing that would be left is a table describing > the ACL. > The only thing I worry about is that users_param is a type of text, > which could be slow for very large sites. Which is why you might want > to have a separate table. Course, the table is entirely indexed. > Just put it in users_param, if it turns out to be a performance > issue it will be easy to fix. > > > The changes are reduced to modify the ACL functions that I have included > > in Slash.pm. Is it the correct place? This changes are minimal. > Well, the ACL functions should be in Slash::Utility. This is the first place where I put them. But the I see that I need to access Slash::DB in this functions and this library is not used in Slash::Utility. remove and add ACLs need to access setUser and getUser which are in the Slash::DB API. So the only place where I found that I can put this functions was Slash.pm. I see that in 1.1.5 admin.pl is now a Plugin. If we follow this idea we can start to work in a new "admin" plugin that uses only ACLs. When this plugin is ok, the slashcode user can choose between the ACLs and the seclev versions. But as you have said, we need only one access control model in the future. It could be cool to have more that one access control system using plugins, but i think that with ACLs we can do everything that is described now with the seclev concept and many other things. Bye -- Alvaro > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development -- =================================================== Alvaro del Castillo San Félix ac...@ba... Barrapunto.com |
|
From: Eric D. <eri...@ja...> - 2001-03-13 10:50:11
|
Ok, I transferred my site over to Bender, but is there supposed to be a slashd daemon running? I can't seem to find it. I'm using FreeBSD 4.2 and Bender 1.1.5...... Thanks! |
|
From: Chris N. <pu...@po...> - 2001-03-13 12:16:56
|
At 02:51 -0800 2001.03.13, Eric Dannewitz wrote: >Ok, I transferred my site over to Bender, but is there supposed to be a >slashd daemon running? I can't seem to find it. I'm using FreeBSD 4.2 and >Bender 1.1.5...... Run "/etc/rc.d/init.d/slashd start" (your path may differ, depending on your OS), either as root (necessary if you have more than one Slash site owned by more than one user), or as the user that owns the Slash site. The slashd daemon is in /usr/local/slash/sbin/, but you should run the init.d script to start/stop it for best results. Running that script will stop/start slashd cleanly, and do it for _all_ slash sites on one system (using the slash.sites file as a guide). -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
|
From: Eric D. <eri...@ja...> - 2001-03-13 18:28:51
|
ok, well, seems that there is NO slashd in /etc/. And freebsd does not have /etc/rc.d path. Maybe it didn't get installed correctly. How do I reconstruct it? Is it pretty much the same thing as slash-1.1.5-bender/utils/slashd? Chris Nandor wrote: > At 02:51 -0800 2001.03.13, Eric Dannewitz wrote: > >Ok, I transferred my site over to Bender, but is there supposed to be a > >slashd daemon running? I can't seem to find it. I'm using FreeBSD 4.2 and > >Bender 1.1.5...... > > Run "/etc/rc.d/init.d/slashd start" (your path may differ, depending on > your OS), either as root (necessary if you have more than one Slash site > owned by more than one user), or as the user that owns the Slash site. > > The slashd daemon is in /usr/local/slash/sbin/, but you should run the > init.d script to start/stop it for best results. Running that script will > stop/start slashd cleanly, and do it for _all_ slash sites on one system > (using the slash.sites file as a guide). > > -- > Chris Nandor pu...@po... http://pudge.net/ > Open Source Development Network pu...@os... http://osdn.com/ > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development -- Back up my hard disk? I can't find the reverse switch! Eric Dannewitz - Adventurer, saxophonist, good-timer (crook? quite possibly), clarinetist, manic self-publicist, part-time flautist(flutist?), macintosher, and often thought to be completely out to lunch. http://www.jazz-sax.com |
|
From: Eric D. <eri...@ja...> - 2001-03-13 18:42:17
|
Hmm, running the slash-1.1.5-bender/utils/slashd via ./slashd start runs the daemon for like about 30 seconds then it quits out. That was due to a directory permission problem. Slashd now started. It wasn't installed in my etc directory, so, I'm using the slash-1.1.5-bender/utils/slashd. Chris Nandor wrote: > At 02:51 -0800 2001.03.13, Eric Dannewitz wrote: > >Ok, I transferred my site over to Bender, but is there supposed to be a > >slashd daemon running? I can't seem to find it. I'm using FreeBSD 4.2 and > >Bender 1.1.5...... > > Run "/etc/rc.d/init.d/slashd start" (your path may differ, depending on > your OS), either as root (necessary if you have more than one Slash site > owned by more than one user), or as the user that owns the Slash site. > > The slashd daemon is in /usr/local/slash/sbin/, but you should run the > init.d script to start/stop it for best results. Running that script will > stop/start slashd cleanly, and do it for _all_ slash sites on one system > (using the slash.sites file as a guide). > > -- > Chris Nandor pu...@po... http://pudge.net/ > Open Source Development Network pu...@os... http://osdn.com/ > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development -- Back up my hard disk? I can't find the reverse switch! Eric Dannewitz - Adventurer, saxophonist, good-timer (crook? quite possibly), clarinetist, manic self-publicist, part-time flautist(flutist?), macintosher, and often thought to be completely out to lunch. http://www.jazz-sax.com |
|
From: Chris N. <pu...@po...> - 2001-03-13 12:20:02
|
At 07:19 +0100 2001.03.13, Alvaro del Castillo wrote: >This is the first place where I put them. But the I see that I need to >access Slash::DB in this functions and this library is not used >in Slash::Utility. remove and add ACLs need to access setUser and >getUser >which are in the Slash::DB API. > >So the only place where I found that I can put this functions was >Slash.pm. No, it's fine to do it through Slash::Utility. Just call getCurrentDB(). You're right that Slash::DB is not "use"d from Slash::Utility; however, it is only ever used in conjunction with Slash.pm, which does, so Slash::Utility has access to the Slash::DB class, which it does use. See createEnvironment(). The architecture of this very well may change a bit to be more clean, but that's not a problem for now. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
|
From: Alvaro d. C. <ac...@ba...> - 2001-03-13 07:50:48
|
Chris Nandor wrote: > > Actually, users_param just uses a text field for "value" now. So the only > issue would be picking a better limit for "name". Ops, in 1.1.5 ... mysql> desc users_param; +----------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------+--------------+------+-----+---------+----------------+ | param_id | int(11) | | PRI | 0 | auto_increment | | uid | int(11) | | MUL | 1 | | | name | varchar(32) | | | | | | value | varchar(254) | | | | | +----------+--------------+------+-----+---------+----------------+ If the value is a text field it is perfect :-) I am going to try to follow your work in the CVS. Now I have installed slashcode 1.1.5 and I am working on it. Bye > > At 18:09 +0100 2001.03.12, Alvaro del Castillo wrote: > >Do you think that this model could replace the seclev model in > >the future? As I say in other email, I have found very easy to make > >co-live the to models in the transition. > > I think so, yes, though there could be something i am not thinking of. > Currently we only use seclev for "is anonymous," "is regular user," "is > author," "is admin." But this would be replaced by things like > "can_unlimited_moderate" etc. in the ACLs. Yes, the ACLs are very descriptive and very clear when other people have to work with them. We have a site that uses this scheme so we can use this experience and the code that we have developed. For example, a little web interface that let the user/admin edit ACLs. I will send patches to the list so you can see the code. Bye -- Alvaro > > -- > Chris Nandor pu...@po... http://pudge.net/ > Open Source Development Network pu...@os... http://osdn.com/ > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development -- =================================================== Alvaro del Castillo San Félix ac...@ba... Barrapunto.com |
|
From: Chris N. <pu...@po...> - 2001-03-13 12:20:04
|
At 07:26 +0100 2001.03.13, Alvaro del Castillo wrote: >Chris Nandor wrote: >> >> Actually, users_param just uses a text field for "value" now. So the only >> issue would be picking a better limit for "name". > > >Ops, in 1.1.5 ... Yep, it was changed back to varchar, and then back to text. > >mysql> desc users_param; >+----------+--------------+------+-----+---------+----------------+ >| Field | Type | Null | Key | Default | Extra | >+----------+--------------+------+-----+---------+----------------+ >| param_id | int(11) | | PRI | 0 | auto_increment | >| uid | int(11) | | MUL | 1 | | >| name | varchar(32) | | | | | >| value | varchar(254) | | | | | >+----------+--------------+------+-----+---------+----------------+ > >If the value is a text field it is perfect :-) Yeah, however, as I noted as a possibility, and Brian echoed, I think it is best if users_acl is a separate table, just to keep it cleaner. Just take the users_param schema from CVS (or this one, changing value to a text field), and duplicate exactly for a users_acl table. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
|
From: Alvaro d. C. <ac...@ba...> - 2001-03-13 14:13:09
Attachments:
slashschema_create.sql.diff
|
Chris Nandor wrote: > > At 07:26 +0100 2001.03.13, Alvaro del Castillo wrote: > >Chris Nandor wrote: > >> > >> Actually, users_param just uses a text field for "value" now. So the only > >> issue would be picking a better limit for "name". > > > > > >Ops, in 1.1.5 ... > > Yep, it was changed back to varchar, and then back to text. > > > > >mysql> desc users_param; > >+----------+--------------+------+-----+---------+----------------+ > >| Field | Type | Null | Key | Default | Extra | > >+----------+--------------+------+-----+---------+----------------+ > >| param_id | int(11) | | PRI | 0 | auto_increment | > >| uid | int(11) | | MUL | 1 | | > >| name | varchar(32) | | | | | > >| value | varchar(254) | | | | | > >+----------+--------------+------+-----+---------+----------------+ > > > >If the value is a text field it is perfect :-) > > Yeah, however, as I noted as a possibility, and Brian echoed, I think it is > best if users_acl is a separate table, just to keep it cleaner. Just take > the users_param schema from CVS (or this one, changing value to a text > field), and duplicate exactly for a users_acl table. Ok, the setUser functions is very flexible and this changes are very easy to do. ¡Great job! And now in the users_param table I save the color which has selected the user for the site (our orange color doesn't like to some of our community), the myslash flag which tells if a user want to have its own slash and the title for the user slash. I send you a patch to create the new table. I have change the field names to describe better the information. The patch is for MySQL but it is also ok for PostgreSQL and Oracle because it's SQL. Now, I am going to change the ACL funtions to Slash::Utility and test everything against 1.1.5. Bye -- Alvaro > > -- > Chris Nandor pu...@po... http://pudge.net/ > Open Source Development Network pu...@os... http://osdn.com/ > > _______________________________________________ > Slashcode-development mailing list > Sla...@li... > http://lists.sourceforge.net/lists/listinfo/slashcode-development -- =================================================== Alvaro del Castillo San Félix ac...@ba... Barrapunto.com |
|
From: Chris N. <pu...@po...> - 2001-03-13 14:20:01
|
At 15:10 +0100 2001.03.13, Alvaro del Castillo wrote: >Now, I am going to change the ACL funtions to Slash::Utility and test >everything >against 1.1.5. We are planning a new beta release today; you might want to either wait for that, or use what is in CVS, rather than doing 1.1.5. -- Chris Nandor pu...@po... http://pudge.net/ Open Source Development Network pu...@os... http://osdn.com/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X