Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


User management in XOOPS 2.3

  • PPCM

    Hello there,

    Before starting development for user management. A little discussion is needed.
    Pemen your experience is really needed...

    Actually, depending on XOOPS version user management is not the same:
    - In XOOPS 2.0.x, user management is done in the core
    - In XOOPS 2.2.x, some functions are in core and some others are in a module

    Make user management as a real module. Features for this module:
    - Keep only some functions signature in the core
    - Allow a module to register as user management (This mean that only one user management can be active at the same moment)
    - Allow developpers to inherit from a basic user management object to develop their own one
    - Keep functionnalities of XOOPS 2.2 in the basic user management object

    What do you thing about this and does something miss?

    • D.J.

      mboyden starts to work in profile module.

      We must keep the profile module as simple as possible, basically adopting the module in XOOPS 2.26 with some bugfixes, so that we can get XOOPS 2.3 ready as early as possible.
      Once we get XOOPS 2.3 stable, we can add new features.

      Keep in mind, we can not afford another multi-branch XOOPS. XOOPS 2.3 is defined solely as the merge of XOOPS 2.2 and 2.0, we must be careful not let it go as a branch in parallel with XOOPS 3.0

    • Mark Boyden
      Mark Boyden

      Yes, I'd like to have anybody's code, such as Pemen's and xoops_gold's to review and incorporate into the module. At the minimal side of things, we'll have 2.0.x user mgmt and 2.2.x user mgmt combined, but then look at pushing that forward.

      There are certainly a few other ideas floating around, and I'd opened a topic on this on X.o and am keeping the wishlist in the X.o wiki. I'll setup a task item here on SF, but I haven't gotten around to it yet.

      I'm in agreement that only the minimal amount needs to remain in the core, but that if the module is deactivated/removed, the basic ones from before need to remain available (IM, TZ, etc.) Realistically, just username/password/email is the most minimal for an account, but we need backwards compatibility still at this point. Thus, I'd likely use an idea similar to what SmartProfile did in that case.

      All of this would be an extension of the XoopsUser object, of course, and DJ has done some work on this for 3 which I'll be reviewing in the next couple of days. I would encourage any follow-up to this discussion to occur on the X.o site in the forums and wiki.

      BTW, a couple of other things that I've remembered but not yet added/seen posted are:
      multiple group adds upon registration
      pre-register with a validation code (one-use only)
      * auto-login (with security risk disclaimer)

      I do not plan to do this work in a closed box, but rather as open as possible with the input and assistance from the community. Anyone that wants to be a part of it should IMHO, as long as we are aligned with the 2.3 merge directives and focusing forward to 3.0 along that path.

      • XoopsGold

        Hi Mark!

        "Yes, I'd like to have anybody's code, such as Pemen's and xoops_gold's to review
        and incorporate into the module."

        Thanks, Mark for your discussion. I actually gave a thought on how to go about BEFORE I applied at SF for a new developers plattform. The reason is as follows:

        The work I did for the association is something that cannot and must not be included as default. The requirements I laid down for the association is very special. Like for example due to legal reasons, one may want to document each and every change. This becomes very important when there are more than one who could admin the profiles module, like the CEO, who needs an access to the members database round the clock and there is someone who also keeps making changes in the data records.

        Also, I am not deleting the members for legal reasons but have setup a status -9 and have made in the criteria like records appear which are > 0.

        Now those requirements are very special an someone who is having a hobby website with xoops may not have any interest at all. But some serious organisation may have to adhere to such coding and it would be a must to have.

        Looking to such a great diversity of interest, I thought of having it as an extended module. Thereby XoopsGold Module would be a totally independent module bringing a lot of new features seperately from the existing profiles module. By doing this, there are a lot of added and hidden advantages.

        My work or coding is not that of an expert nature like many here, to be very honest and therefore also remains different packed in a seperate module. Further, it will use all the activities of the profiles module anyway, like field creation, etc.

        I have made steped registration procedure through members. So currently the registration takes place from the front-end in a form using the profiles module registration function + form, whereas there is anathor file named accounts.php that generates an account-assistent and helps all the members within an association to install accounts thereby building a user-database kind of an address-book converting Xoops in kind of a virtual office. The assistent works and interfaces with forms step-by-step like step one would be a check of an email-address only, fail if exists and save time, true and go-forward and have those data included in the database by applying that record to be included in the group press or hospital, etc.

        Now, the CEO could select user records with many critereas and send mass mails based on group based or selection based, etc. Here there is a seperate templyting system, kind of very basic integrated. So selecting a simple template, it offers tags like {X_MRMRS} and it will address very accurately querying the db, who is being addressed and write Dear Mr. Bush or Dear Miss Nathalie, etc.

        Further, if there is a password resetting, because there was a mass import, then the passwords are generated, included in clear-text format in the email, templated selected, MRMRS tags used, passwords inserted with md5 in the db, etc.

        As you could see, there are a lot of routines developed that helps in day-to-day life of a heavy membership management routine thereby making Xoops not only intelligent but also saving a considerable ammount of time. I am not paid and all I am doing is to program one after the other functions making things automated, easy, and workable or atleast saving the boring aspect of an unpaid job.

        This was the reason why I decided to NOT TO HAVE IT INCLUDED ANYWHERE and have it seperate. Because they are very special and could be installed if required if necessary. The module will use BTW the same profile table in a dynamic manner.

        What I am now developing is alo methods of display of user and members records in the backend. Currently all those areas are really underdeveloped but works. They need to be changed drastically and revised tremendously if it has to be released for the general public use. For this also I need time, kind of a few months as Xajax would be a bit tricky.

        As you could see, I am working on the comforts of membership and accounts management rather than USER MANAGEMENT (it may sound funny but its a different world), which needs to be done due to legal reasons.

    • Garrath

      Sorry for my bad english

      We can change the implementation of an abstraction by an other implementation, if there have as less the same interface.

      We can have a XoopsUser class like actually and we can have an other implementation where you can't physicaly delete member. That the great possibility of OO.

      If i want an other column in the user for adding sexe because i want to make a meeting site, i just want to change the XoopsUser.
      If i don't want to having a physicaly delete of user, i just want to have change on delete method.

      This is right for user but for anything else in xoops core.
      If i don't want to use the actual PM, i just want to have another class choice.

      And if we do this, Xoops can evoluate easily.

      But before that, sorry because i had say it before, the core must be refactoring for using the good way (use xoops_gethandler, don't have different class with same name, don't have sql query in code, etc...)
      I think this is the first step, after we can have a reflection on feature, we can have reflection for solution, evolution etc...

      If xoops is refactoring like this, normally after, all sql query must be in core class. Then after is more easily to change db by another one, or change db by xml, or flat file.
      After you can see that there is some missing feature in xoopsObject, or near xoopsObject, like edit form. Look if i just want add a new attribut on xoopsUser, i may adding column to the table (or use another table), i may adding it in intvar OK. But after this new attribut must be edit. If i want this can be evoluate easily where i put the list of editing zone? how i manage this?

      I think there is a mistake here to think user is a particular problem, i think FIRST we can have a general way to all kernel class. The solution for user must be the same for PM, avatar or anything else...

      • XoopsGold

        By: Garrath (garrath_fr) - 2008-01-14 16:58

        "I think there is a mistake here to think user is a particular problem, i think FIRST we can have a general way to all kernel class."

        Very correct. The members.php and users.php requires an overhaul.

        "we can have an other implementation where you can't physicaly delete member."

        I have said in my earlier post that I have simply modified the related functions NOT_TO_DELETE an user physically. I set the level to -9 and made sure that all other areas would care ot the status -9 as a "notionally deleted" user. Now if this is done right from the kernel as an extended status, that would be even better, as it has an impact on Xoopsmialer, login, registrations, etc. To have a better management one needs more status as a global.

        What I find missing is if the kernel could have a couple of extra detections of groups hierarchies and categories.


        Currently, the groups are independent to each other. That means the same status could be applied by setting in an extra field xoops.groups.level just like users.

        Such a concept generates a world of possibilities:

        There could be also a compatible level like in users -9 as a notional deleted user. Having a group with the level -9 sets the kernel as deleted group. A level 0 means that it is a temporary group where user records are landing in this group that needs to be sorted out. level 9 is the highest level (as contrast to -9) where super user belongs to that group.

        So any level between 1 and 8 could be set to create different hiearchies and inter-related co-hesiveness. Thereafter groups are interrelated.


        Example: There are different users belonging to different groups BUT ALL HAS AN ACCESS to find users. Those groups are related to the designation and rights (worker, chief officer, CEO) that a user belonging to that group may have and that differs. Then different hierarchies level will show different results in the find users searches. This could help in devising a system of designation to be realised in the grouping structure of Xoops.


        Designing the hierarchies, it could be helpful if there is an extra parameter string value that could be passed in the function which could change the result display, etc.

        Now the above misses in the current user management. Unless some more features are added, there are less possibilities of new and creative solutions, if the core remains the same, keeping apart of those necessary cosmetic changes of displays and maxlengths, etc.

        A must, must, must is that Xoops 2.3 needs to be a merge only version as phppp said in his earlier post. So the above would apply to a long term overhaul or lets say 2.4!!!

        • Ashley

          I have a thought here:

          why not extend the entire xoops object class to always have the following attributes?

          row_status enum(active, suspended, defunct)default active
          Normal usage is in active state. But administrator or process may want at some point to suspend a data row for some reason temporarily. A defunct row, can no longer be used going forward but is kept so that historical dependencies don't break.

          row_dt: datetime
          Date and time of last row change

          row_uid: int
          The id of the user that last changed the data row

          It allows data to go offline whilst keeping it in the system. You simply change the CRUD functionality so that a delete defuncts a record. You could extend the paradigm to CRUD-TSA i.e. T = Trash - trash the record completely. S = Suspend - take record offline not allowing users to use it. A suspended record can be re-activated. A defuncted record cannot. A = Activate - bring record back on-line.

          From a SQL perspective, you simply add "AND row_status='active'" to all read queries unless overidden in the call, and usually for admin usage only.

          I don't claim to have invented this, I came across it on a project back in the 80's and its made sense to me to use this simple auditing and record management system practically ever since.

          If it helps :-)

          • XoopsGold

            By: Ashley (akitson) - 2008-01-15 18:18

            "why not extend the entire xoops object class to always have the following

            I had to create in the root/include/functions.php further includes of different function files written by me which would serve the entire installation.

            Now, if I sit down until someone in the core team would have the inspiration to modify it, I simply added the functions.

            Those things could have been avoided if the XoopsUsers and XoopsObjects is upgraded to ATLEAST what you have written. By this the rows will have an added sensitity in fetching the data thereby handling of the fields would become better.

            This will however not solve a situation that the row_fields also needs to belong to a group hierarchies. Simply by clicking a field_property and mapping as to which group could have edit_search_view perperty is now not enough.

            Currently, I am batteling with many situations and developing many many functions AFTER WAITING FOR YEARS to have some work done and help a non-profit.

            Helpful Statuses would be not just from the view point of registrations and some practical handling of the data /Active/inactive/defunct/ but from the view point of memberships records, that could also be even preconfigured, like /Active/Deleted/Unpaid/Nomail/ kind of thing.

            Hence it is not just a basic and fundamental access level but kind of A TAGGING SYSTEM of a user record, where the basic access level is anyway included.

            Currently, I have a new field called "SupervisionLevel" for each record. This is a field created in profiles module 2.2.6 and the fields are pre configured, for instance /Fax_received_for_registration/User_resigned_membership/To_call/ etc. Those statuses changes and are stored in the field of each record. This field is generated in the find users and made searchable.

            Now if such a system is applied to the Kernel Objects, then somehow a lot of things could be used for different modules and certain services could be offered or not offered based on the status.

            At the moment, what happens to the status DOES_NOT_AFFECT the other modules except to that of access or no access belonging to a group.

            This is in my view a situation that could be explored and developed to apply for practical reasons.

    • Garrath

      Sorry for my bad english.

      I take example of physicaly delete or not because you give it, it's just an example of different implementation.

      Group you can have different way to manage it:
      *1 a user can be in different group.
      For group, we can define a group by his differents between an other one. Example:
      In default we have :
      - webmaster
      - register user
      - anonymous

      a webmaster is a register user with more right. Then we just have to put on webmaster group the adding rights.

      We have an other group, in example, redactor.
      redactor have the same right of register user, with one to edit news. Then redactor group have just this right.

      A group herit the rigth from another group.

      Actually, if you put only difference between groups, it's working. But is not easy to make it.

      *2 user can be in one group
      All rigt are define group by group, then a user is in one group and just one.


      But technicaly, that is just group and normaly we can have different implementation of manage group. It need more work that adding attribut on user, but it's the same in fact. We need to have an interface for group with right calcul and all we need. After we can have different implementation, and her manage form.

      • XoopsGold

        By: Garrath (garrath_fr) - 2008-01-15 10:15

        Group you can have different way to manage it:
        1 a user can be in different group.
        2 user can be in one group

        The WORST POSSIBILITY is *2! After working with profiles module extensively, I could easily claim that this would not work and be extremely restrictive.

        What I suggested is a user could belong to different groups. Xoops will currently assign, I beleive, the lowest rights to a user belonging to two or many groups.

        To unserstand my suggestion how it opens a different area of possibilities is in the example below:

        Have Groups with names as follows
        1. Webmaster
        2. Registered User
        3. CEO
        4. Team_Leader
        5. Finance_and_Accounts
        6. HelpDesk

        All the above groups have admin permission to "find users", "edit users", and "email to users" module that would allow the admin to search and edit the user records.

        Currently, the find users search mask will display everything the same to all of the users and also display all the fields to everyone.

        Having Hierarchial system of groups, one could obtain hierarchies parameter from the kernel itself and then apply for the display on the groups. So thereafter

        CEO + Webmaster could see every thing and edit the entire record of a user while HelpDesk could see some limited fields and enter i.e. Feed some more data depeinding on the support given or required making a documentation field known as "HelpDesk_Notice" (MediumText field property).

        The Users belonging to a group Finance_and_Accounts could see fields related to bank accounts that HelpDesk cannot and must not see it.

        It is therefore a system is required from the fundamental SQL Queries from the CORE itself. If this functions are not included in the centralised system of Kernel Objects, then one has to extra code within the profiles module to be able to have those features.

        Now having in the kernel, it will also help all the other modules as the permission system will then become even more precise and granular.

    • Garrath

      sorry for my bad english

      My english is poor then i have lot of difficult to make me comprehensive sorry...

      I put

      because i think there more than 2 way to manage group.

      The 2nd way is not worst than the one or another way. It depends on context and what kind of site do you have.
      Actually you can have the twice way with xoops. I think there is lot of site with the 2 because it's easy. On my site we have the 1.

      For me, the core must give the architecture that after we can have the choice of implementation we need.
      I think it's more difficult here than add a attribut on xoopsUser because it doesn't need just another class, but also a application gestion, and also don't forget that module can have a group right gestion too.

    • XoopsGold

      Hi Ashley!

      row_status enum(active, suspended, defunct)default active
      row_dt: datetime
      row_uid: int

      I have implemented this with the following situation and have created the following fields:

      In the table users the following:


      In the user_profile

      created_by >>>>> Installed one and no one has permission to this field.
      remote_addr >>>>> changing field for each login, documenting the IP Address in the protocol field constantly
      last_modified_by >>>>> compared last and today to write in the protocol.
      last_modified_am >>>>> compared last and today to write in the protocol. Here, I have created to insert the loginname and insert as this never changes.
      to_email_choose_template >>>>> Status tag set during working by different teams.
      last_email_sent_status >>>>> Says if an email was sent on which date and includes in the protocoll
      last_email_sent_am >>>>> ditto
      unsubscribekey >>>>> a key which will invoke an event trigger, like unsubscribe, or even some agreement like yes or no
      observation >>>>> Comment field
      config_package >>>>> a package applied by a manager or CEO to work on that user record, like the user does not have an address because the post came back, so the account is made inactive, all the address fields are set to unknown, email sent to some people, etc...
      webmasterpad >>>>> Above changes related to config_packages, changes in the account field data are dociumented in this med.text field.

      protocoll >>>>> a med.text field to document all the account changes done from creation date, adding to old & make new, send an email to all responsible for record management

      resync >>>>> To have a resyncronisation stamp of records within a database

      So an extensive membership record maintaining could be undertaken with the above.