HOME       >>       Staff Room

I Want To Do More But... Things have to improve


iGuest

For those with little time, the main points is, bring Xisto's reputation back up, allow us to handle more members and to cut back on our time. All this involves reworking our form, and ways we handle things now.

 

M^E has let me into the approval/denial of hosting including the ability to authorise hosting but since being given that power (this would have been quite some months ago), I have not actually approved any hosting I have approved my first one now and the reason being is what we currently undertake to approve hosting is too time consuming and I have to say that you guys who approve hosting I am in awe because I understand how long this process must take. Unfortunately for me, this process is too long so in these days, weeks and months I want to work on ways that we can reduce time in approving accounts and making it viable to do.

 

Temporary solution:

 

The moderators are no different to us administrators, so I think that their job in rejecting an application has been good. The thing with approval however is, it's still the admins job to review these posts (as I understand) and make sure it's fine to authorise their hosting.

 

This is a time consuming area and I don't know why we can't let the moderators think that if a person is acceptable in getting hosted, to say so (just posting a simple acknowledgement in their thread saying the believe this User is acceptable for their hosting package requested), we can trust our moderators can't we, doesn't mean we will give them power to authorise hosting, but at least they can tell us Yes or No for hosting someone.

 

That way, we just need to check on their decision and authorise it or not. If there's no acknowledgement then we should not wait for a mod to post that yes or no if we can check it ourselves and if you don't have time to authorise it but you've checked it, then we too should be able to say 'Yes' so that someone else with the power to give hosting can look at it and just host it.

 

What we can do in the meantime:

 

What I want to do or see is our form that is used for members to fill out for hosting, get a major clean up and made more logical for us, that is all the required information that we need to make decisions should go at the very top, the rest of the information we gather can go below.

 

The way the form is now, the information we require to make our decisions is all over the place. So this should be fixed. Also is this the only way we know if a member is requesting hosting, if we view this forum?

 

Just viewing this forum is too time consuming I believe, so why not have alternative means of storing the data we require, like emailing it or storing it in a database, or something alongs the lines of that.

 

The database storage method would be quite good, as we could work on scripts that will grab this data and present it to us in an easy to read way for us, and if integrated with IPB, then we can also gather the information we need to check posts of these members.

 

There's so much we can do to this form to eliminate the member from hosting at the beginning instead of them wasting their time posting in the forum the code gotten back from the form.

 

Maybe later down the line, it can be sped up even faster with scripts to help us understand whether a post is plagurised or the amounts of words per post or some type of statistical information that we could look at that will just say great, lets host them or hose them. IPB stores quite a lot of statistical information about a post as it is, and we could use these statistics to help us.

 

Another interesting thing about IPB is COPPA, which is used for validating members via email, now how about working on something similar that allows us to validate a person waiting for Hosting, this way, we can see who's waiting to be hosted too.

 

I do not mind if I spend months working on scripting that will help us speed up the process, as it is, this would take a long time for me to find time to get round to doing this, but in the end it should hopefully be all worth it and maybe it will boost Xisto back up, I can even integrate it within IPB if needs be or work on an external form that can still work with IPB so that the request for hosting forum is it's own special forum where only users with enough hosting credits could get in there, otherwise why have people requesting hosting if they don't meet the minumin hosting credits? (we could even stop it at the form before hitting the forums)

 

This will save our time and the mods time. So disallowing them inside the requesting forum is one step to eliminating time wasted.

 

I just want to see Xisto get back to how it was, the less members we had the easier our work was, but the increase of members is actually bringing our status down and if anything, it's affecting Xisto's reputation.

 

I don't want to actually dump all of this upon our mods though so that they have their time wasted too, but we got to find a short term way to speed up hosting now or else we're just going to keep punishing ourselves. What do other hosts in these fields do with similar requirements (forum posting)? It'd be interesting to know how they go about it, especially if they have it automated.

 

If anyone has anything else to add to this, then by all means do so, especially in areas I may have overlooked.

 

Cheers,

 

MC


vujsa

I can pretty easily modify the current in any order required but since I can't say for sure what information should come when, I can't really reorganize it without input.

 

I used a sample that NilsC did as the template but the form is pretty staright forward in the output section so modifications ar easy. Please let me know what order or information is needed for the output.

 

I wrote the request script because the requests used to really be hard to get information from. Most people weren't providing all of the information requested in their post and there wsn't any order to it. I admit that the form is not very efficient for various reasons. The script itself is one of the first practial scripts I had written and it's inability to directly input the data to the forum has been a major issue.

 

I had at one point in time outputed an error if a member didn't have enough credits for the hosting package they requested but changes in the member credit check script required me to remove that option. That script seems to be working again as it used to but the new credit script is broken now.

Old Script (working): https://support.xisto.com/

New Script (broken): https://support.xisto.com/

 

I can implement the feature again if needed.

 

I agree with you that the entire process is kind of tedeous. I've looked into solutions for auto posting the application which would require the script be moved to the astahst account.

 

There are a few items that should be added to the application automatically.

Credits earned

Posts made

credits per post (avg)

characters per word (avg)

words per post (avg)

reading level per post (avg)

Link to the search results of the members posts for a quick view of the posts made by the member.

I can show you how to calculate the average reading level if needed. The higher the level, the greater the chance that the post is of higher quality and in turn the more likely it is plagiarized. Perhapes add a flag to posts that only staff can see if the reading level is particularly high so that the post can be checked.

 

I think that by adding a few tools and moving the request form to the astahsot server will prove to eliminate much of the time consuming aspects of the approval process. Of course this will require us to rely on the information given by the script. Then we can do random checking and our normal moderating to find problem members.

 

I'll look into some options for implementing this type of system here but I fear that I may not have the needed skills to program much of it.

 

vujsa


pyost

New Script (broken): https://support.xisto.com/

Now that you mention it, the scripts on the process page do need some fixing. I think they've been broken for a few month now, and that's not good for the reputation. It seems that there as some problems when it comes to connecting to the database.

As for improving the approval system, I think it could be done with only a few minor changes. As vujsa, already said, moving the application form to the Asta server is on of them. Also, adding more useful info in the application (generated by the server) could speed up the process. I think EVERYTHING can be done as long as we all collaborate.

Jeigh1405241495

This would be a good thing to attack, more and more people are complaining (and therefor annoying the hell out of me) about requests taking too long to be processed. I know most of the active mods would be willing to help green light people worthy of hosting so that it doesn't all fall on the mod's shoulders. Less people waiting for hosting means less people to deal with complaining about it. Plus seeing that a mod green lights there account would also make most people calm down, since they'd realize it is indeed only a matter of time.Clean up the forms/scripts, let the mods be a bit more influential, I think it could smooth itself out nicely.


vujsa

After giving this some thought, I now believe that a form can be rather easily developed that can use the availible database information. There a copule of things I'll need help with like the auto post to forum but I think this can be overcome.

 

I investigated the possibility of using a third party IPB interface system to post the applications but OpaQue seemed unsure of the script. It is a beta version but never gets to a "STABLE" release because IPB upgrade come along so often. Last I checked it was a 1.6.0 beta 4 release But previous was a 1.5.0 beta release.

 

The script is pretty stable and with MC's assistance, I'm sure that it can be properly secured if needed.

 

I'll make an attempt to develope a suitable script at IPBGaming.com where have access to the IPB database.

 

I'll need some information from OpaQue about the table and field where a user's credits are stored which is probably something like ibf_members / credits.

 

The hardest part will be writing the needed formulas that will evaluate all of the members posts. Database query optimization isn't my strong suit. So getting all of the members posts and evaluating them may be stressful for the server.

 

 

So here is what I am thinking so far. Form not totally unlike the one currently being used will do the following when submited:

Get member ID based on the member's inputted username.

Check the members credit count and compare to amount needed for the hosting package requested.

- Return error if insufficient number of credits are available

Get the memebrs number of Actual posts (If a memebr has had some posts deleted, the count in their record is usually wrong)

Calculate the average number of credits per post.

Read all of the user's post minus quoted and coded information and get the total number of words used for each.

With the raw text only section of the post, the script then performs the following actions:

Get average number of words per post

Get the average number of letters per word

Get the average number of syllables per word.

Get the number of 3, 4, 5, and 6+ syallable words used.

Get the average number of words per sentence.

- These calculations will bu used to determine the posts size, reading level, and general quality

The script would then output (post) an application to a read-only forum which staff may post in but users can't edit their "useful" information! This will ensure that the application is authentic but a request ID number would help determine if a post was copied and pasted with a search.

 

In the application as it is posted in the forum the following extra information will be added:

A link to the search results of all of the users posts for quick review. currently it requires at least two clicks to get there so this will speed that up.

http://forums.xisto.com/index.php?act=Searer&mid=2714

A link to the search results for the request ID to confirm that the post is authentic. This may need to be done in the external script since it will require the use a the GET method.

I'll try to get something together in the next week or so. Seems like I got a bunch of unfinished projects right now.

 

Later we can try to add features like plagiarism checking but I think that most of use can spot a suspicous post pretty well and just need to do a search or two.

Maybe an additional script that will use a cut and paste url to search on several search engines and get results...

 

Let me know if you have any suggestions.

 

vujsa


iGuest

Apart from how ugly the form is now (does need a cosmetic change) we could make it simple.

 

Now I'm not sure how the creating hosting form works, but I believe every form will need to be altered and should work together.

 

For example, I know for a fact that the application form does not neccessarily reflect what the user uses for creation. There's no check on their domain name that they said they'd use and what they could put in. So if I said my domain is going to be this.astahost.com, I could use the creation form and actually do that.astahost.com which means the information submitted in the forum is incorrect. Same goest with the account username, another thing that might have to be looked at.

 

So the hosting application has to seamlessy work with the creating host form. Members details will be updated to reflect information they use, I believe there's fields created that the User must fill in with their account name and site, or was this removed due to security reasons? I can't remember except I knew there was a discussion about this. Anyways, we can secure this so that sensitive information like the username is hidden, while it'll be safe to publish their website address.

 

The basic information we need from our members is pretty must just their:

Forum name

Forum password

With that information, we can then use IPB's database to get all the statistical information (password is only for confirmation it's that user). Of course we can still grab other information just for knowing more about our members, their interests, etc.

 

This information will then be inserted into the forums.

 

The creating host form will be the one that does the domain name/username.

 

This information will then be appended, or added to the same thread where their information was added. That way, it reflects more accuracy.

 

Behind the scenes, we will automatically add to the members details the information that reflects their host, accountname, etc.

 

We then need our own form, that processes the approved/denied hosting and informs the members of the outcoume via their email.

 

So I'm going to go over the information we currently get from our forms, there's many ways to do everything automated, just knowing the best way is the hardest:

 

We're getting their domain name, this is too soon in the process, maybe good to know but if this is the case it doesn't mean it's accurate. If we are to grab this information now, we need to make sure that this is automatically set for that user upon creating their hosting, so they have no ability to alter it, unless we provide a means to do so.

 

The account name, too soon in the process, again should follow the domain name means.

 

Introduction, that is not so important.

 

Email address, not really important, we will use the email address used in IPB, and will do all we can to make sure users know that their email address used here is where their hosting will be sent.

 

Age, not important, could use IPB's information on this.

 

Country, not important, could use IPB's information on this.

 

Website theme, slightly important, gives us the general idea of what the site will be used for. Maybe we should use checkboxes and give them categories to select instead, that way if Xisto ever wanted to create an ultimate index for their members, we can use this information to categorise it and allow people to look within our own member sites for things of interest.

 

The reason for picking Xisto, well, yes and no, it's really for our own internal use of knowing things that we need to make sure we keep it up.

 

Finding Xisto, another internal thing, but helps us figure out where we're lacking with marketting.

 

Previous host, well knowing the competition is always a good thing.

 

Reason for leaving that host, again, knowing the competition, seeing where they're failing and hopefully we manage not to do the same.

 

Hosting package, not really important, hosting package should be automatically selected based on their hosting credits, because if they do have a high amount of credits and only go for package 1 they lose them all right?

 

Additional comments, a bit important but can remain at the end of the form, this is where users leave important notes.

 

The agreement, very important, submission should not take place unless this agreement is selected. Also it's got to stand out and not be tucked away.

 

So really we need to work on the process that this all happens as well as making sure the information we require is near the top.

 

From the hosting application to the creating form, it's all got to work together on information gathered from the hosting application, we also should limit the hosting application to that user once and only once, so once filled in, if any problems, we will have to create another form that can deal with their problems incase of something going wrong.

 

I haven't even talked about the scripting side of things yet, but I'll go over IPB's code, dissect their database and post information and understand how all this takes place.

 

Cheers,

 

MC


pyost

we need to make sure that this is automatically set for that user upon creating their hosting, so they have no ability to alter it, unless we provide a means to do so.

I'm not sure if I understood you well, but you want to forbid members to edit their requested domain/user name? This doesn't have to be complicated at all - we could just disable the EDIT function in the request forums, which is easy with IPB.

Age, not important, could use IPB's information on this.Country, not important, could use IPB's information on this.


Unfortunately, 90% of the users do not input this information, so it might be good to request at least the age. It's good to know how old a contributor is.

For example, I know for a fact that the application form does not neccessarily reflect what the user uses for creation. There's no check on their domain name that they said they'd use and what they could put in. So if I said my domain is going to be this.astahost.com, I could use the creation form and actually do that.astahost.com which means the information submitted in the forum is incorrect. Same goest with the account username, another thing that might have to be looked at.

Why should there be an account creation page? It should all be done automatically after an application gets approved. However, there should be some kind of verification - let's say a user has seven days after getting aproved to verify the account, or it gets deleted.

vujsa

Well, I played around a little at IPBGaming.com to see how much trouble it would be to gather certain information and using ipb-sdk, I was able to quickly throw something together.

Since I don't have access to the Xisto database nor to the server, I used the IPBGaming.com forum as the testbed. Since IPBGaming doesn't use the credit system, that data isn't included.

The forum there is much less formal I guess but the stats still give a general idea of the user's contribution. The script takes several seconds to process because it has to cycle through all of the posts a member has made to generate the stats it is asked for. The test script doesn't exclude certain information like quoted text and code so a person that quotes others frequently will either gain or lose based on the writting style of the person quoted. I'll try to clean that up a bit.

The scoring system is pretty accurate in many cases but I was surprised that I scored so high.

Here is the link:
http://forums.xisto.com/no_longer_exists/
This link will be removed soon!


Remember that this is just a sample of what is possible for us to use and it takes a LONG time to process.
The process time won't be an issue for new hosting requests since the majority of applicants have less than 20 posts...

The data could easily be inserted into a new database table which could then be auto-inserted into the hosting setup form used by the Admins.

The same effect can be recreated without ipb-sdk but would require much more coding.

Any thoughts?

vujsa


iGuest

Hey Pyost,Our members don't have the ability to edit their posts as it is. What I'm saying is the way things are now, they fill out the hosting application form, and then they submit the results back into the forum. When we approve their accounts, they get sent an email to go to the page to create their hosting, now this is what I mean by they have the ability to change what they told us. Here at the creating host form they can input another domain, which does not mean it'll reflect what they told us in the forum.As for Age being important, my decisions aren't based on a person's age. That's what this thread is about, having the important information that makes a decision to approve hosting or deny hosting. I don't care about the rest to be honest, reading all that is just going to take up more of my time. However, these things should be considered, but at the moment, I'm looking at ways to speed up our process rather than slow it down, maybe if we get the process going smoothly and a lot quicker, we'd have time to sit back and read what they have to say.All I would need is their forum name, their hosting credits and access to their posts (that's how it is now but the process of getting all this is long, especially their posts and that we must come into the forum to do so). From there I then use other information to form the approval message (which is just a text file that I alter to fit that user) used to approve their accounts. Things like account name, domain name, package and email address however these things mean "jack" if they are still able to choose whatever account name, domain name they want when at the creating host form. Their package however can't be changed, their email address is that of IPB.You're right about the creating host form, we can eliminate it but the reason I left it in was to show how we currently do things, because of our application form, if our application form catered to everything, there would be no need to have the creating hosting form, but it doesn't at this stage.As for vujsa, Those stats are exactly the type of things I'd be interested in using. There's more that I would want though as I thought it felt naked (meaning I don't understand how these calculations came to be), so I would also like to grab keywords from a persons post, ignore the common words, grab a list of their most frequently used words, that way I can understand what they like talking about and get a feel of their knowledge.To check a post for plagurism, creating our own tool for this will take a while is this what we want to do? I tried online ones, and they are not accurate enough as I was able to get pass content that I just browsed on the web for and tested against. I can get the source code for many plagiarising software used within schools (but it's not really needed), which usually only check against all student materials to make sure they never copied from each other, they then usually use a paid subscription to turnitin.com or something like this which I don't think we'd look into paying for anything.So what plagiariser tools are out there that I can view and evaluate. The ones that partially work weren't too bad, however they must be used from their site, and it'd probably be best to do it that way than to bypass their means (which I know is possible but we'd be sending a lot of traffic to them, which they'd eventually block).I may consider writing our own one, but at this point in time, not yet.Cheers,MC


vujsa

Our members don't have the ability to edit their posts as it is.

 


Actually, that all changed when we upgraded last time as the new credits script accounts for edits, deletions, topic removals, etc... Has really reduce the staff workload a bunch.

 

Those stats are exactly the type of things I'd be interested in using. There's more that I would want though as I thought it felt naked (meaning I don't understand how these calculations came to be), so I would also like to grab keywords from a persons post, ignore the common words, grab a list of their most frequently used words, that way I can understand what they like talking about and get a feel of their knowledge.

 


The averages are pretty straight forward. Count the number of words in a post and the number of sentences in a qualifying post to get the word/post, words/sentence, and sentences/post. Assign that value to each post and add all of the posts together and divide by the number of qualifying posts. Also, the posts are also searched for the number of words with 3 syllables or more. The reading level is calculated based on the number of words in a sentence, the number of sentences and the average number of words in a sentence with three or more syllables.

 

A quallifying post is one which is in a forum category where posts count towards your total cumulative post count.

 

Here is the code that this is based on: http://forums.xisto.com/no_longer_exists/

 

 

IPB has a problem where the total cumulative post count isn't corrected when a qualifying post is deleted so there will be some discrepencies with that.

 

There are additional calculations I will work on.

Average number of lines of code in the members posts.

List of and frequncy of keywords like you suggested.

Members most common forum categories.

Number of external links in members posts.

Average time between posts

Number of back to back topics started by a user.

The first will give us an idea if the user is a programmer or if he is copy and pasting content from other sources.

The second will show the user's interests

The third also will show us what the member is most interested in.

Number of external links will show if the user is a spammer or lacks knowledge in the topics he is posting about. Small posts with a lot of external links may be helpful to other users but may be spm and is certainly not very enriching or original material.

If the average time between posts is small this will show if the user is working as quickly as possible to just get his post count (credits) up, copy and pasting, or spamming us. Usually when a user manages to get several posts submitted in a very short time, the posts are very small, spam, or plagiaerized.

The number of back to back topics started will usually show the same information as the average time between posts. We usually get 5 or so new topics started each day so if one person starts 3 or more of those, it usually is a bad sign.

I think that finding or building a plagiarizer finder may not be required if we can do a better job of spotting the warning signs. Most bad members have a hard time hiding the fact that they suck!

 

vujsa


iGuest

To be honest, I would love if there was a plagiarise checker and that it intercepted their post before it even hit our forums, though not deny the post, but make it invisible if suspected to be plagiarised, so that we can confirm for ourselves that it is or isn't.I am also thinking Zero Tolerance, instant Banning for plagiarisers. I am sick of dealing with them, and even sick of discovering this when they want to be hosted.I briefly looked at the script on readability, interesting concept indeed, flawed but still interesting and I guess provides a good enough value we could use, however still got to eliminate those divide by zero problems that aren't even considered in this code.Cheers,MC


vujsa

Yeah, the divide by zero was a shock the first time I ran the script. ;)I did a little playing with it an decided that the best solution was to use division by one instead of zero. This will probably work itself out once formating is removed from the text and code is ignored. Other problems with the script is the way it determines the number of sentences and the number of words.The only problem with a plag filter for posts is that it would probably result in much longer page loads. I'm guessing any plag filter we may design would perform a number of searches on a multitude of search engines and major websites which get plagiarized frequently. Like the microsoft website. Found an artcle copied from them this week. :)Even if most of the work was done on the third party servers, our server would have to wait for them and sort through the results. Found another plagiarized post this week which was from a website that copied it from us. I like the idea of setting the suspected plagiarized post invisable because frequently by the time I notice a problem topic it has multiple replies and the deletion process decreases everyones credits that was active in the topic by 1.5 times the amount of credits earned when they posted. The new credit system works much better and isn't very nice to bad members. Quarantining suspect posts would prevent good members from being punished for replying to bad topics. ;)Since I'm not convinced that a plag filter script is our best choice, and lean more towards identifying posts that need to be checked by a human, I think that using the statistical calculations I've suggested to set a post invisable and auto-report the post may be better. This would flag possible junk posts, spam posts, and plagiarized posts for further examination. As for the Zero Tolerence Policy, I'm all for it. I can't ban a member but I have suspended several for 999999 days. Usually with a message in the email that they can request to have their account unsuspended by PMing me. They can't PM because they are suspended. They can't even complain about not being about to PM! I'm not alway very nice I guess.At IPBGaming a mod was installed to harrass problem members. They keep getting logged out without reason, etc... If you had some other method of searching for plagiarism, I'd like to hear about it.vujsa


vujsa

After some investigating, here is what I have found:

As I see the entire process, this is what happens. Correct me where I am wrong:

Member fills out the req_form.php script and pastes the output to the free hosting request forum.

The admin reviews the request and the members history approves hosting.

The admin turns to the "ADMINISTRATOR CONTROL FOR APPROVING ACCOUNTS" to set a hosting token for the member and sends the approval email.

The user goes to the create account page and enters his forum usernam, forum password, desired domain name, account username, and account password.

The script checks the members file to determine if his username and password match and a hosting token was set.

The script then inserts the domain name, account username, and account password into the hosting server.

The hosting server then processes the information and generates an account for the user with the data specified.

The server returns data to the user via the hosting creation script.

The user logs in and begins using his site.

Where does the admin pick the hosting package?

After a hosting token is set, what information is return or required to proceed?

Am I missing something here?

 

Seems that there is two parts to the system. The server side and the forum side which requires the admin to set data for independently and is similar for the user. So I'm guessing after a hosting token is set on the forum side, there is a form to add the hosting account details to on the server side. Is this correct?

 

vujsa


iGuest

The token is the hosting package, no information required or returned except an automated email is sent to the person via the email address stored in IPB with details of creating their host, Somewhere along this process before or after creation, the member is placed in the HOSTED group.Anyways I decided to get IPBSDK and see how it could help.I downloaded the ipbsdk, unzipped it, configured it and then tested it and wasn't impressed that it didn't comply with error_reporting(E_ALL|E_STRICT), so I spent a few minutes fixing that script up. Little things like this annoy me, it's not like I spent hours or days fixing this, only a few minutes and yet when I encounter developers who suggest turning off errors, warnings, etc I can only think it's due to laziness or lack of understanding. Not only would fixing these small things help, it'd lower their support for the questions asking why such and such errors are showing up. I notice they blame IPB for the problems, well when integrating with IPB, I think they should at least comply with what IPB expects, IPB as far as I can see complies with E_ALL levels, so why can't ipbsdk.Anyways, now that I have ipbsdk, I would like to work on things that first, speed up our processing.Cheers,MC


vujsa

I'm sorry, I forget to mention before. I'm told that OpaQue may be upgrading to IPB2.2 in the near future. If that is the case, perhapes we can try to get a packeage together for him before that. Of course, we'll need him to provide us with the scripts he used to begin with. He can delete the specifics which he may be concerned with for security reasons but we don't need the specifics just the general.

 

He would have to modify whatever code we write to fit the server/database. Oh and do the testing for us.

 

I don't see any reason why the "ADMINISTRATOR CONTROL FOR APPROVING ACCOUNTS" form can't accept the account username, account password, and domain name and save them for later use by the member. These would be hidden of course or added after the fact (between the form and the process).

 

The better I understand the forms OpaQue wrote, then less complex things seem to me. Seems like the only difficult part is the interface with Web Host Manager which OpaQUe has already created so we just need the admin side of the script rewritten.

 

So here is how I think the new system should work:

User fills out and submits a request for hosting application.

Th application will then check the users credits, and generate some statistical information about the users forum habbits.

The application, if enough credits are available, will then post the application, a public version, in the forum and save ALL of the data in a new database table like hosting_apps.

An admin can review a list of pending hosting applications (with the information provided that has already been discussed) and chose the application the admin will work on next.

The Admin can deny the application and provide a reason which will basically close the application and auto reply to the members forum based application with a reason.

- OR -

The admin can approve the hosting application which will set a hosting token for the member, send the hosting approve email and auto reply to the forum application.

The user can then go to the creation form and chose the password that they want to use for their hosting account.

I think the hardest part of this will be generating the list of pending/denied/approved applications and displaying the data for that application. The only reason I think this is the hardest part is becuse I think that the Admin should have various tabs to use to view the various types of data about the user. All pages of the Admin interface should have "Approve" and "Deny" buttons for one click approval or denial!

 

Now on to the credit check! It would be nice to know where the accumulated credits for a member is stored instead of reading the output from a different script. I'm guessing it is either a table by itself in the IPB database or and added field in the astahost_members table. Actually, I think it is 2 fields; total_credits and starting_timestamp.

$credits = $total_credits - ($starting_timestamp - time());
or something like that.

 

So now all we need to do is write the scripts. This will work even without the added statistical information or plagiarism check we have discussed and save the approving Admin quite a bit of time.

 

Now just to get the required information needed from OpaQue.

 

vujsa


iGuest

What can we do now?The reason I'm asking is, if we can do the things that can change now, we can work on the other things later.Here's what I'm thinking for the process:When a user reaches the minimal hosting credits to apply for hosting, he will automatically be sent a PM/email, detailing instructions on how to apply for hosting. His group will be altered to something that means "able to request", I'm not sure what a good name for the group would be. That group will let him have access into the Free Request Forum as well as all the other forums. The instructions inside the email/PM he's sent will detail how he can apply for hosting as well as things to help them make sure that their request will not be denied.This user then goes to the hosting application form, fills in the needed details, the form will insert his request into the forum, his status will be changed to "awaiting approval", the form will verify his username and password. We will PM/email that user again? with the link to their request and also what they can expect. The information supplied from the form along with his user statistics will be stored for administrator to review, also other information like viewing all their posts made, possibly integrating it with our ACP (admin control panel) or a seperate protected area within Xisto that acts the same way.The information will allow us to provide the Denial/Approval using our own form, maybe we should have 3 strikes and they're out if denied that many times or zero tolerance on things that just cheat the system. If denied, it will be inserted into their thread for requesting, as well as emailed/PM to them, we will state the reasons for denial, this form will also have the ability to ban them and we will provide reasons why we banned them in a section we can fill out. When denied, their group will be changed to something that means "under review", which should be a set time limit of say 1 week, which will remain onhold till then, and will not be visible by any of the admins until the time limit has been reached. We will go through the same process, and if 3 strikes, the account will no longer be able to request hosting. Is that a good thing? It will be put in an "unable to get hosting" group.The approval does similar to the denial process, except it's job will be to make sure that everything to create their hosting happens, the approval will be inserted into the forum, an email/PM will be automatically set, sending basic instructions on how to use their hosting and providing them with detail information about connecting and using their host. The package given is automated based on the number of credits they have. However I think we need more insight on how the hosting credits are done, because I want to see each credits given for a particular post and be able to adjust their credits by adding/removing them, especially 1 liners that accumulate credits, I would zero it out. The hosting credit script may already do this, but it's still something I would want to see, especially if it can be improved.I don't think I've left anything out except the details of what each form needs and how we are to handle the form and how it's all managed.I've left out the plagiariser for now, this is not going to be part of the hosting process, it'll be part of the posting topic/thread. Also there's a lot of minor things I would want to do to our forums, giving us more control on how things are done, for exampe when information is quoted from another site, they have to cite where they got the information from, if not, the plagiariser will get them for this, because anything they've gotten which is not their own, must be acknowledged, that way the plagiariser will check that site and insure that the information can be found there (even if it can be found elsewhere too, it will use the site cited over anything else). If they don't I think penalising them could be automated, giving them a warning, then the plagiariser will fill the location of the cited site for them if it can verify a high accuracy of the content. If not, it will not do anything, since the plagiariser works only on posted, it might be a good idea to ignore edits or only check changes with possibly a backup/cache of it.Anyways what do you think about this process, I know it'll be confusing to understand, because from thoughts to here, things don't come out in the right order unless I re-evaluate everything again.If you need information on what the forms will have, I can also write that. If you're unsure how I'm going to do anything on this, ask and I'll provide code to help explain it better.Cheers,MC


vujsa

I think this is a good flow chart and think that implementing these types of changes and additions will really help to ensure that good members are getting their hosting applications approved quickly and poor members are given their denial even more quickly. :PI'll help out anywhere I can but the real issue is getting access to the server from OpaQue. I can create dozens of forms and scripts but unless I have access to the database, it won't do much good. I suggest that you hook up with OpaQUe on IM sometime to discuss your ideas or at least have hime read this topic. Until we get some partisipation from OpaQUe, I think we are at a standstill. I can only do so much at IPBGaming since it doesn't use the credit system or interact with WHM and the hosting creation process.vujsa



VIEW DESKTOP VERSION REGISTERGET FREE HOSTING

Xisto.com offers Free Web Hosting to its Members for their participation in this Community. We moderate all content posted here but we cannot warrant full correctness of all content. While using this site, you agree to have read and accepted our terms of use, cookie and privacy policy. Copyright 2001-2019 by Xisto Corporation. All Rights Reserved.