xoops-trackers Mailing List for XOOPS Web Application System

Bugs item #1408568, was opened at 2006-01-17 17:35
Message generated for change (Settings changed) made by phppp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1408568&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.2.x
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Registered users cannot change their own e-mail address.

Initial Comment:
Hi,

Here's the problem, I as an administrator of my site
(using Xoops 2.2.3 and the PM module that came with it)
I can change my own registered e-mail address, as well
as all of the users e-mails, BUT registered users, who
do not have any admin priviledges cannot change or
update their own e-mail address.

I've tried the following: "Go to admin > preferences >
extended profiles > general settings. Towards the
bottom of page, select yes to "Allow users to change
email address?"."

But that doesn't seem to work at all, users are still
stuck with their originally registered e-mail, and
nomatter which setting I try nothing works.

If you have any ideas or solutions to this please
e-mail me at ale...@gm... or PM me at xoops.org
my username is alex1182.

Thanks,
Alex

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

Comment By: Nobody/Anonymous (nobody)
Date: 2006-01-17 17:47

Message:
Logged In: NO 

Could someone please delete my post above I found a solution
here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1370632&group_id=41586&atid=430840

please delete my post I don't want my mailbox spammed.

Thanks guys.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1408568&group_id=41586

Bugs item #1418855, was opened at 2006-01-30 13:29
Message generated for change (Comment added) made by phppp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1418855&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules - Members
>Group: XOOPS 2.2.x
>Status: Pending
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misplaced bracket results in unfilled list

Initial Comment:
In /class/xoopsform/formselectuser.php there is a close
graphics brackt ({) at line 94. This should be moved to
follow line 89.

The corrected code looks like this:

if (!is_array($value)) {                              
                                                      
                 $value = array($value);              
                                                      
                          }                           
                                                      
                                          
if(is_array($value) && count($value)>0) {             
                                                      
                     $id_in = "(".implode(",",
$value).")";                                          
                                             
$criteria->add(new Criteria("uid", $id_in, "IN"));    
                                                      
 } <==== moved to here
$criteria->setSort('name');                           
                                                      
             $criteria->setOrder('ASC');              
                                                      
                          $users =
$member_handler->getUserList($criteria);              
                                                      
   
$select_form->addOptionArray($member_handler->getUserList($criteria));
                                                      
              
<==== moved from here                                 
                                                      
             $action_tray = new
XoopsFormElementTray("", " | ");                      
                                                
$action_tray->addElement(new XoopsFormLabel('', "<a
href='###' s discuss on xoops.org

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

Comment By: phppp (phppp)
Date: 2006-01-31 15:17

Message:
Logged In: YES 
user_id=1001493

OK, I'll take care of this one personally. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1420150&group_id=41586

Bugs item #1420150, was opened at 2006-01-31 00:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1420150&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules - Forum
Group: XOOPS 2.2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Display of read/unread postings

Initial Comment:
Submitted by Takayoshi Sasano <tc...@do...>

Posting as a regular User, logging out and back in as
different user. Posting is displayed as read.

Reply to posting, logging out and back in as first user
used in this test. Forum/posting is displayed unread.
clicking on the forum marks the whole forum as read, no
matter if the unread posting is clicked or not.

Versions used in this test:
xoops 2.2.3 Final
cbb 2.32

This misbehaviour is reproducable, unfortunately this
really destroyed a project to migrate a page with
static content and a standalone phpBB into this nice
system. Would be really nice if these things get fixed
one day - this state is unchanged for years now.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1420150&group_id=41586

Feature Requests item #1420141, was opened at 2006-01-31 09:35
Message generated for change (Settings changed) made by xoops_gold
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1420141&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 1
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "AUTOSAVE" can be a core feature?

Initial Comment:
Hallo!

Can this ne a core feature?

I mean, in any form generated by any core function or
module, if the core scripts are sensitive to saving
function that would be very good.

The data can be saved in an extra table. The field
names could then be: input_1, input_2, etc. A general
table where all the data being typed by the users in
the form would be saved every min. or 3 min. Like forum
or article or PM. If there is a crash for any reasons
the form data is instantly lost.

With this feature, they could be restored by username
and module associated data. In the user blocks it could
appear as drafts like it is with Gmail.com!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1420141&group_id=41586

Feature Requests item #1420141, was opened at 2006-01-31 09:35
Message generated for change (Settings changed) made by xoops_gold
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1420141&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
>Priority: 1
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: "SAVE" can be a core feature?

Initial Comment:
Hallo!

Can this ne a core feature?

I mean, in any form generated by any core function or
module, if the core scripts are sensitive to saving
function that would be very good.

The data can be saved in an extra table. The field
names could then be: input_1, input_2, etc. A general
table where all the data being typed by the users in
the form would be saved every min. or 3 min. Like forum
or article or PM. If there is a crash for any reasons
the form data is instantly lost.

With this feature, they could be restored by username
and module associated data. In the user blocks it could
appear as drafts like it is with Gmail.com!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1420141&group_id=41586

Feature Requests item #1420141, was opened at 2006-01-31 09:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1420141&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: "SAVE" can be a core feature?

Initial Comment:
Hallo!

Can this ne a core feature?

I mean, in any form generated by any core function or
module, if the core scripts are sensitive to saving
function that would be very good.

The data can be saved in an extra table. The field
names could then be: input_1, input_2, etc. A general
table where all the data being typed by the users in
the form would be saved every min. or 3 min. Like forum
or article or PM. If there is a crash for any reasons
the form data is instantly lost.

With this feature, they could be restored by username
and module associated data. In the user blocks it could
appear as drafts like it is with Gmail.com!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1420141&group_id=41586

Bugs item #1418855, was opened at 2006-01-30 10:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1418855&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modules - Members
Group: XOOPS 2.3.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Misplaced bracket results in unfilled list

Initial Comment:
In /class/xoopsform/formselectuser.php there is a close
graphics brackt ({) at line 94. This should be moved to
follow line 89.

The corrected code looks like this:

if (!is_array($value)) {                              
                                                      
                 $value = array($value);              
                                                      
                          }                           
                                                      
                                          
if(is_array($value) && count($value)>0) {             
                                                      
                     $id_in = "(".implode(",",
$value).")";                                          
                                             
$criteria->add(new Criteria("uid", $id_in, "IN"));    
                                                      
 } <==== moved to here
$criteria->setSort('name');                           
                                                      
             $criteria->setOrder('ASC');              
                                                      
                          $users =
$member_handler->getUserList($criteria);              
                                                      
   
$select_form->addOptionArray($member_handler->getUserList($criteria));
                                                      
              
<==== moved from here                                 
                                                      
             $action_tray = new
XoopsFormElementTray("", " | ");                      
                                                
$action_tray->addElement(new XoopsFormLabel('', "<a
href='###' \' before any char among
reserved chars: "a",
"A","B","c","d","D","F","g","G","h","H","i","I","j","l","L","m","M","n","O","r","s","S","t","T","U","w","W","Y","y","z","Z"

//  
//
// insert double '\' before 't', 'r', 'n'
//
define("_TODAY", "\To\d\a\y G:i:s");
define("_YESTERDAY", "\Ye\s\\te\\r\d\a\y G:i:s");



Instead of doing like the comments say above (which is
complicated and could lead to errors if date function
is changed again), just use \\ before any char you want
printed out.

// changed code above to this:
define("_TODAY", '\\T\\o\\d\\a\\y G:i:s');
define("_YESTERDAY", "\\Y\\e\\s\\t\\e\\r\\d\\a\\y G:i:s");

this should probably be updated before other hosts
switch to 5.1


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

Comment By: phppp (phppp)
Date: 2006-01-29 23:00

Message:
Logged In: YES 
user_id=1001493

OK, I'll take care of this one personally. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1407616&group_id=41586

Bugs item #1411964, was opened at 2006-01-22 05:55
Message generated for change (Comment added) made by phppp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1411964&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Modules - News
Group: XOOPS 2.2.x
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: notifications.php 

Initial Comment:
xoops 2.2.3

http://www.max-pt.net/notifications.php
/modules//article.php?storyid=22 

404 


wrong url.

/modules/[b]news[/b]/article.php?storyid=22

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

>Comment By: phppp (phppp)
Date: 2006-01-29 22:58

Message:
Logged In: YES 
user_id=1001493

It is for "news" module

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

Comment By: Nobody/Anonymous (nobody)
Date: 2006-01-23 13:27

Message:
Logged In: NO 

same in 2.2.3

in notifications.php 

http://www.max-pt.net/modules//article.php?storyid=5

??

here is the module name?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1411964&group_id=41586

Bugs item #1412858, was opened at 2006-01-23 09:32
Message generated for change (Comment added) made by phppp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1412858&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.2.x
Status: Open
Resolution: None
>Priority: 7
Submitted By: Dave Lerner (dave_l)
>Assigned to: phppp (phppp)
Summary: Blocks won't display on admin index page for https

Initial Comment:
[2.2.3a-final]

Blocks won't display on admin index page for https URL.

Here's a fix:

In kernel/module.php, in XoopsModule::getCurrentPage,
change:

if (preg_match('!^http://!i', $relative_url)) {

to:

if (preg_match('!^https?://!i', $relative_url)) {

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

Comment By: phppp (phppp)
Date: 2006-01-29 22:57

Message:
Logged In: YES 
user_id=1001493

OK, I'll take care of this one personally. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1412858&group_id=41586

Bugs item #1412870, was opened at 2006-01-23 09:47
Message generated for change (Comment added) made by phppp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1412870&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core -  Core
Group: XOOPS 2.2.x
Status: Open
Resolution: None
>Priority: 7
Submitted By: Dave Lerner (dave_l)
>Assigned to: phppp (phppp)
Summary: Profile module search - page navigator

Initial Comment:
[2.2.3a-final]

In Profile module search function, page navigator fail
to works correctly.

Here's a fix:

modules/profile/search.php

After:

    if ($total_users > $limit) {
        $search_url[] = "op=results";

Insert:

foreach
(array('uname','uname_match','name','name_match','email','email_match')
as $param) {
   if (isset($_REQUEST[$param])) {
      $search_url[] = "$param={$_REQUEST[$param]}";
   }
}


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

Comment By: phppp (phppp)
Date: 2006-01-29 22:56

Message:
Logged In: YES 
user_id=1001493

OK, I'll take care of this one personally. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1412870&group_id=41586

Patches item #1349677, was opened at 2005-11-06 15:48
Message generated for change (Comment added) made by phppp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430842&aid=1349677&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: XOOPS 2.2
Status: Open
Resolution: None
>Priority: 7
Submitted By: Dave Lerner (dave_l)
>Assigned to: phppp (phppp)
Summary: No PM notification method option if no PM module

Initial Comment:
[XOOPS 2.2.3-final]

I'm attaching a patch that removes the Private Message
option as a notification method on the Edit Account
page, if the Private Message module is not installed or
not active.

Although this patch works, it's really ugly, and I hope
someone can come up with a more elegant solution.

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

Comment By: phppp (phppp)
Date: 2006-01-29 22:55

Message:
Logged In: YES 
user_id=1001493

OK, I'll take care of this one personally. 

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

Comment By: Dave Lerner (dave_l)
Date: 2005-11-12 09:51

Message:
Logged In: YES 
user_id=936559

I'm updating the patch.  I made a minor tweak for efficiency.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430842&aid=1349677&group_id=41586

Feature Requests item #1417524, was opened at 2006-01-28 19:12
Message generated for change (Comment added) made by xoops_gold
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417524&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 2
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: UNIX Permission system from CORE to modules and inheritance:

Initial Comment:
Hallo!

I was checking other systems and framework in this
regards. Hence I came to the following idea:

If the group permissions are based on the unix
permission system like 777 (Global full access), 700
only user has full access, it would be the best and
ideal solution. The complexicity of the permission
system of unix is in the heads of all the xoops users
and developers.

Now if this system of permission concept is
integigrated into the Xoops permission concept, it
gives an extra-ordinary value to Xoops in regards to
its complexity. Those groups numbers would be read in
the early phase of the call through index.php anywhere.

Therefore, it could be taken forward into various
modules. For e.g.:

If the Admin or a user uploads a file, it can be
mentioned what level should Xoops would understand the
permission as, when the file remains on the server.

This therefore would be seperate to the group permissions. 

Now, Xoops offers groups (permissions)
.........but......not......permissions.....itself! Then
those permissions could be also inheriten by objects
that follows through the data_calls.

Whens the (unix) permissions (through groups) are
originally offered and saved, it would make the core
very different to all other systems as this quality NO
OTHER SYSTEM HAS ACHIEVED!

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

>Comment By: Xoops_Gold (xoops_gold)
Date: 2006-01-29 21:04

Message:
Logged In: YES 
user_id=1329834

Hallo!

Very interesting. Was just surfing and found out that this
what I suggested is really nothing new but has already been
implemented. In this computer world have no surprises with
similar situations! ;-)

Here you can see:
http://www.awf-cms.org/

Ofcourse, I should have mentioned that in Xoops Core
permissions, there cannot be execute permissions. Hence it
could only be access, write and delete.

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

Comment By: Xoops_Gold (xoops_gold)
Date: 2006-01-29 12:30

Message:
Logged In: YES 
user_id=1329834

Hallo Skalpa!

I suggested earlier to have a module <> permission <> groups
table linking. This message is here:

http://sourceforge.net/tracker/index.php?func=detail&aid=1404819&group_id=41586&atid=430843

Thinking on it, I thought that it would be better to have a
strong permission system which is NOT module related but
really PERMISSION QUALITY related. Here the best possibility
is ofcourse Unix system as described above.

OK, I checked in the db and found out which and where:

IN the table xoops_group_permission

......gperm_name.......

has been a place to play by all the module developers.

This funny play has been going on since there has been no
disciplinary and controlling sub_routines available in Xoops
Core. If there was anathor table available to define the
quality with the name

........xoops_permission_type...

where the quality of Unix permissions would be stored, then
the module developers would simply have to insert those
numbers like 700 of 777 unix permissions. With this system
the core and all modules would understand the system of
permissions.

Therefore, I suggest the following:
1. --------------------------------
Make a new table xoops_permissions_link

perm_id   perm_name   perm_type
1.........rwxr-xr-x...0755
2.........rwxrwxr-x...0775
3.........rwxr--r--...0744
4.........rw-r--r--...0644

2. --------------------------------
Apply the quality of permissions to modules.

There cannot be a group permissions assigned to a group in
this theory.

The modules would have the user, group and system
permissions anyway. Hence,

User = Site Account or vHost or $SiteGroup ist the
owner/User of a module
Group = Group within a site
Other = Everyone, Server and system functions

3. --------------------------------
Table xoops_group_permission 
>>>>> gperm_name Field Name change to >>> gperm_id

May be this may be interesting to discuss! Shall I make a
sketch with tables of this idea? Does this idea make sense?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417524&group_id=41586

Feature Requests item #1417839, was opened at 2006-01-29 09:01
Message generated for change (Comment added) made by xoops_gold
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417839&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Administration
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 1
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cache and Preferences requires seperation

Initial Comment:
Hallo!

I noticed a major difference after I made some changes
in the system preferences under:

modules/system/admin.php?fct=preferences&op=showmod&confcat_id=1&mod=1

So If I want to have one new theme selected I need it
to be atleasted listed through the system preferences
for it to appear in the themes block.

Updating or submitting this, it deleted the entire
cache. But this is not what I wanted. I did not change
or wanted to change aningthing in the chache. Simply
changing anything in this form deletes everything in
the chache folder.

This slows down the entire site. There were blocks and
modules with 1 Month chache preference.

I beleive that there should be a clear seperation
between the two, like Cache controller annd Preference
Manager...

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

>Comment By: Xoops_Gold (xoops_gold)
Date: 2006-01-29 13:27

Message:
Logged In: YES 
user_id=1329834

Hallo Herko!

Thanks. You are right. I meant that there are functions in
this form that are not cache related. Changing them should
not destroy chache. Thats what I mean...For instance:

1. Changing User name for Guests
2. Name of User cookies.
3. All sessions related, length, name, etc...
4. Debug mode...
5. Banner activate...
etc...

Thats what I meant...However this is a very small thing....I
just wanted to draw attention and did not actually mean to
ask a feature or bug/complain...My Xoops is horribily slow
on a vServer with dynamic pages. I am forced to work with
cache...


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

Comment By: Herko Coomans (herkocoomans)
Date: 2006-01-29 10:26

Message:
Logged In: YES 
user_id=441189

Actually, this behaviour makes sense. When you change
something in your general settings, which are site-wide by
default, you want these changes to resolve throughout the
whole site immediately, and not just after a month. For
instance, if you switch to another template set, you want to
see the effect immediately, not after the time all the
blocks have 'expired' their cache lifetimes.
Plus, it's only the lifetimes that are reset, so the site is
only a bit slower for the very first person that sees the
pages again, because at that time the new cached versions
are generated and used for consecutive visits.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417839&group_id=41586

Feature Requests item #1417524, was opened at 2006-01-28 19:12
Message generated for change (Comment added) made by xoops_gold
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417524&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 2
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: UNIX Permission system from CORE to modules and inheritance:

Initial Comment:
Hallo!

I was checking other systems and framework in this
regards. Hence I came to the following idea:

If the group permissions are based on the unix
permission system like 777 (Global full access), 700
only user has full access, it would be the best and
ideal solution. The complexicity of the permission
system of unix is in the heads of all the xoops users
and developers.

Now if this system of permission concept is
integigrated into the Xoops permission concept, it
gives an extra-ordinary value to Xoops in regards to
its complexity. Those groups numbers would be read in
the early phase of the call through index.php anywhere.

Therefore, it could be taken forward into various
modules. For e.g.:

If the Admin or a user uploads a file, it can be
mentioned what level should Xoops would understand the
permission as, when the file remains on the server.

This therefore would be seperate to the group permissions. 

Now, Xoops offers groups (permissions)
.........but......not......permissions.....itself! Then
those permissions could be also inheriten by objects
that follows through the data_calls.

Whens the (unix) permissions (through groups) are
originally offered and saved, it would make the core
very different to all other systems as this quality NO
OTHER SYSTEM HAS ACHIEVED!

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

>Comment By: Xoops_Gold (xoops_gold)
Date: 2006-01-29 12:30

Message:
Logged In: YES 
user_id=1329834

Hallo Skalpa!

I suggested earlier to have a module <> permission <> groups
table linking. This message is here:

http://sourceforge.net/tracker/index.php?func=detail&aid=1404819&group_id=41586&atid=430843

Thinking on it, I thought that it would be better to have a
strong permission system which is NOT module related but
really PERMISSION QUALITY related. Here the best possibility
is ofcourse Unix system as described above.

OK, I checked in the db and found out which and where:

IN the table xoops_group_permission

......gperm_name.......

has been a place to play by all the module developers.

This funny play has been going on since there has been no
disciplinary and controlling sub_routines available in Xoops
Core. If there was anathor table available to define the
quality with the name

........xoops_permission_type...

where the quality of Unix permissions would be stored, then
the module developers would simply have to insert those
numbers like 700 of 777 unix permissions. With this system
the core and all modules would understand the system of
permissions.

Therefore, I suggest the following:
1. --------------------------------
Make a new table xoops_permissions_link

perm_id   perm_name   perm_type
1.........rwxr-xr-x...0755
2.........rwxrwxr-x...0775
3.........rwxr--r--...0744
4.........rw-r--r--...0644

2. --------------------------------
Apply the quality of permissions to modules.

There cannot be a group permissions assigned to a group in
this theory.

The modules would have the user, group and system
permissions anyway. Hence,

User = Site Account or vHost or $SiteGroup ist the
owner/User of a module
Group = Group within a site
Other = Everyone, Server and system functions

3. --------------------------------
Table xoops_group_permission 
>>>>> gperm_name Field Name change to >>> gperm_id

May be this may be interesting to discuss! Shall I make a
sketch with tables of this idea? Does this idea make sense?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417524&group_id=41586

Feature Requests item #1417839, was opened at 2006-01-29 09:01
Message generated for change (Comment added) made by herkocoomans
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417839&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Administration
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 1
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cache and Preferences requires seperation

Initial Comment:
Hallo!

I noticed a major difference after I made some changes
in the system preferences under:

modules/system/admin.php?fct=preferences&op=showmod&confcat_id=1&mod=1

So If I want to have one new theme selected I need it
to be atleasted listed through the system preferences
for it to appear in the themes block.

Updating or submitting this, it deleted the entire
cache. But this is not what I wanted. I did not change
or wanted to change aningthing in the chache. Simply
changing anything in this form deletes everything in
the chache folder.

This slows down the entire site. There were blocks and
modules with 1 Month chache preference.

I beleive that there should be a clear seperation
between the two, like Cache controller annd Preference
Manager...

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

>Comment By: Herko Coomans (herkocoomans)
Date: 2006-01-29 10:26

Message:
Logged In: YES 
user_id=441189

Actually, this behaviour makes sense. When you change
something in your general settings, which are site-wide by
default, you want these changes to resolve throughout the
whole site immediately, and not just after a month. For
instance, if you switch to another template set, you want to
see the effect immediately, not after the time all the
blocks have 'expired' their cache lifetimes.
Plus, it's only the lifetimes that are reset, so the site is
only a bit slower for the very first person that sees the
pages again, because at that time the new cached versions
are generated and used for consecutive visits.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417839&group_id=41586

Feature Requests item #1417839, was opened at 2006-01-29 09:01
Message generated for change (Settings changed) made by xoops_gold
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417839&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Administration
Group: XOOPS 2.x
Status: Open
Resolution: None
>Priority: 1
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cache and Preferences requires seperation

Initial Comment:
Hallo!

I noticed a major difference after I made some changes
in the system preferences under:

modules/system/admin.php?fct=preferences&op=showmod&confcat_id=1&mod=1

So If I want to have one new theme selected I need it
to be atleasted listed through the system preferences
for it to appear in the themes block.

Updating or submitting this, it deleted the entire
cache. But this is not what I wanted. I did not change
or wanted to change aningthing in the chache. Simply
changing anything in this form deletes everything in
the chache folder.

This slows down the entire site. There were blocks and
modules with 1 Month chache preference.

I beleive that there should be a clear seperation
between the two, like Cache controller annd Preference
Manager...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417839&group_id=41586

Feature Requests item #1417839, was opened at 2006-01-29 09:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417839&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cache and Preferences requires seperation

Initial Comment:
Hallo!

I noticed a major difference after I made some changes
in the system preferences under:

modules/system/admin.php?fct=preferences&op=showmod&confcat_id=1&mod=1

So If I want to have one new theme selected I need it
to be atleasted listed through the system preferences
for it to appear in the themes block.

Updating or submitting this, it deleted the entire
cache. But this is not what I wanted. I did not change
or wanted to change aningthing in the chache. Simply
changing anything in this form deletes everything in
the chache folder.

This slows down the entire site. There were blocks and
modules with 1 Month chache preference.

I beleive that there should be a clear seperation
between the two, like Cache controller annd Preference
Manager...

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417839&group_id=41586

Feature Requests item #1417524, was opened at 2006-01-28 19:12
Message generated for change (Settings changed) made by xoops_gold
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417524&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
>Group: XOOPS 2.x
Status: Open
Resolution: None
>Priority: 2
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: UNIX Permission system from CORE to modules and inheritance:

Initial Comment:
Hallo!

I was checking other systems and framework in this
regards. Hence I came to the following idea:

If the group permissions are based on the unix
permission system like 777 (Global full access), 700
only user has full access, it would be the best and
ideal solution. The complexicity of the permission
system of unix is in the heads of all the xoops users
and developers.

Now if this system of permission concept is
integigrated into the Xoops permission concept, it
gives an extra-ordinary value to Xoops in regards to
its complexity. Those groups numbers would be read in
the early phase of the call through index.php anywhere.

Therefore, it could be taken forward into various
modules. For e.g.:

If the Admin or a user uploads a file, it can be
mentioned what level should Xoops would understand the
permission as, when the file remains on the server.

This therefore would be seperate to the group permissions. 

Now, Xoops offers groups (permissions)
.........but......not......permissions.....itself! Then
those permissions could be also inheriten by objects
that follows through the data_calls.

Whens the (unix) permissions (through groups) are
originally offered and saved, it would make the core
very different to all other systems as this quality NO
OTHER SYSTEM HAS ACHIEVED!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417524&group_id=41586

Feature Requests item #1417524, was opened at 2006-01-28 19:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417524&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: UNIX Permission system from CORE to modules and inheritance:

Initial Comment:
Hallo!

I was checking other systems and framework in this
regards. Hence I came to the following idea:

If the group permissions are based on the unix
permission system like 777 (Global full access), 700
only user has full access, it would be the best and
ideal solution. The complexicity of the permission
system of unix is in the heads of all the xoops users
and developers.

Now if this system of permission concept is
integigrated into the Xoops permission concept, it
gives an extra-ordinary value to Xoops in regards to
its complexity. Those groups numbers would be read in
the early phase of the call through index.php anywhere.

Therefore, it could be taken forward into various
modules. For e.g.:

If the Admin or a user uploads a file, it can be
mentioned what level should Xoops would understand the
permission as, when the file remains on the server.

This therefore would be seperate to the group permissions. 

Now, Xoops offers groups (permissions)
.........but......not......permissions.....itself! Then
those permissions could be also inheriten by objects
that follows through the data_calls.

Whens the (unix) permissions (through groups) are
originally offered and saved, it would make the core
very different to all other systems as this quality NO
OTHER SYSTEM HAS ACHIEVED!

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1417524&group_id=41586

Feature Requests item #1416122, was opened at 2006-01-27 09:50
Message generated for change (Comment added) made by xoops_gold
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1416122&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 9
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: SiteConfigurator $sitegroup in xoops_config_category_options

Initial Comment:
Hallo all!

I have extensively used the multisite module by Mr. Jan
Pederson for about 21 subsites. Through this I saw that
it could be really very very difficult to configure all
of them. Ofcourse this was just a module that did a
perfect job. 

However, I think that if some of the fundamental
factors in the new development is layed, it would be
excellent.

Giving thoughts to this wish, I came to the following
idea and wish that it could be implemented:

There are 3 tables that are really controlling
everything within xoops database. If there was one more
field $sitegroup in the exististing database, that
would really solve the entire problem. 

By doing so, the existing tables of xoops_config,
xoops_category and xoops_configoptions an extra
dimension  to work with that through this the entire
database could be used and multiplied. Hence the field
$sitegroup would be the main multi-plicator of the
entire database.

Therefore, it would be necessary to have the first
PRIMARY TABLE as the MASTER TABLE known as
xoops_sitegroups!!! This table would then be
responsible to install one or more sites.

This is the table that would then be responsible during
the BOOT SEQUENCE by the kernel of xoops. In this
table, some basic information would be stored, like
paths and other informations.

During the installation, the installer will only
install the primary site and make the access possible.
Thereafter it would be possible to get in the
administration.

Hence, this follows a theory, that all the other tables
that are required should also get the variable fields
like xoops_modules, xoops_blocks, xoops_groups, etc.

Also, here in the PRIMARY TABLE as the MASTER TABLE,
there could be possibily a field $lang that tells the
code of the language givin a multi-language feature.

The only thing which in each and every table that
should be refected is the $sitegroup variable! That
shall bring a multisite and multi-language feature to
the entire database!!! 

Does this idea of mine make sense?

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

>Comment By: Xoops_Gold (xoops_gold)
Date: 2006-01-27 10:10

Message:
Logged In: YES 
user_id=1329834

Hallo!

I am placing this in the xoops forum as a message for
further discussions:

http://www.xoops.org/modules/newbb/viewtopic.php?topic_id=46343

Thanks

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1416122&group_id=41586

Feature Requests item #1416122, was opened at 2006-01-27 09:50
Message generated for change (Settings changed) made by xoops_gold
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1416122&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
>Priority: 9
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: SiteConfigurator $sitegroup in xoops_config_category_options

Initial Comment:
Hallo all!

I have extensively used the multisite module by Mr. Jan
Pederson for about 21 subsites. Through this I saw that
it could be really very very difficult to configure all
of them. Ofcourse this was just a module that did a
perfect job. 

However, I think that if some of the fundamental
factors in the new development is layed, it would be
excellent.

Giving thoughts to this wish, I came to the following
idea and wish that it could be implemented:

There are 3 tables that are really controlling
everything within xoops database. If there was one more
field $sitegroup in the exististing database, that
would really solve the entire problem. 

By doing so, the existing tables of xoops_config,
xoops_category and xoops_configoptions an extra
dimension  to work with that through this the entire
database could be used and multiplied. Hence the field
$sitegroup would be the main multi-plicator of the
entire database.

Therefore, it would be necessary to have the first
PRIMARY TABLE as the MASTER TABLE known as
xoops_sitegroups!!! This table would then be
responsible to install one or more sites.

This is the table that would then be responsible during
the BOOT SEQUENCE by the kernel of xoops. In this
table, some basic information would be stored, like
paths and other informations.

During the installation, the installer will only
install the primary site and make the access possible.
Thereafter it would be possible to get in the
administration.

Hence, this follows a theory, that all the other tables
that are required should also get the variable fields
like xoops_modules, xoops_blocks, xoops_groups, etc.

Also, here in the PRIMARY TABLE as the MASTER TABLE,
there could be possibily a field $lang that tells the
code of the language givin a multi-language feature.

The only thing which in each and every table that
should be refected is the $sitegroup variable! That
shall bring a multisite and multi-language feature to
the entire database!!! 

Does this idea of mine make sense?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1416122&group_id=41586

Feature Requests item #1416122, was opened at 2006-01-27 09:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1416122&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: XOOPS 2.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Xoops_Gold (xoops_gold)
Assigned to: Nobody/Anonymous (nobody)
Summary: SiteConfigurator $sitegroup in xoops_config_category_options

Initial Comment:
Hallo all!

I have extensively used the multisite module by Mr. Jan
Pederson for about 21 subsites. Through this I saw that
it could be really very very difficult to configure all
of them. Ofcourse this was just a module that did a
perfect job. 

However, I think that if some of the fundamental
factors in the new development is layed, it would be
excellent.

Giving thoughts to this wish, I came to the following
idea and wish that it could be implemented:

There are 3 tables that are really controlling
everything within xoops database. If there was one more
field $sitegroup in the exististing database, that
would really solve the entire problem. 

By doing so, the existing tables of xoops_config,
xoops_category and xoops_configoptions an extra
dimension  to work with that through this the entire
database could be used and multiplied. Hence the field
$sitegroup would be the main multi-plicator of the
entire database.

Therefore, it would be necessary to have the first
PRIMARY TABLE as the MASTER TABLE known as
xoops_sitegroups!!! This table would then be
responsible to install one or more sites.

This is the table that would then be responsible during
the BOOT SEQUENCE by the kernel of xoops. In this
table, some basic information would be stored, like
paths and other informations.

During the installation, the installer will only
install the primary site and make the access possible.
Thereafter it would be possible to get in the
administration.

Hence, this follows a theory, that all the other tables
that are required should also get the variable fields
like xoops_modules, xoops_blocks, xoops_groups, etc.

Also, here in the PRIMARY TABLE as the MASTER TABLE,
there could be possibily a field $lang that tells the
code of the language givin a multi-language feature.

The only thing which in each and every table that
should be refected is the $sitegroup variable! That
shall bring a multisite and multi-language feature to
the entire database!!! 

Does this idea of mine make sense?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430843&aid=1416122&group_id=41586

Bugs item #1415777, was opened at 2006-01-26 22:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1415777&group_id=41586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core - xml rpc 
Group: XOOPS 2.0.x
Status: Open
Resolution: None
Priority: 5
Submitted By: Marco (marcoxoops)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml rpc and debug mode set to on

Initial Comment:
xml feed is not working when debug mode is set to on
xoops 2.0.13.2
marco


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=430840&aid=1415777&group_id=41586