Paul

That's unusual.. I assume the clients had a different ID internally in MySQL but the same ID code? How far apart did these clients register? Do you have any records from MySQL prior to cleaning it up?

There's not a cPanel only account import, but there is a process to adding cPanel accounts to Blesta if Blesta did not create them. Just follow these steps: https://docs.blesta.com/display/user/cPanel#cPanel-ImportingcPanelAccounts

Someone mentioned that they got this to work, I'm assuming it was you? You should be adding the directory name digitaloceanmodule to /components/modules/, which contains the module files. Then, under Settings > Company > Modules > Available, Digital Ocean should appear with an "Install" button.

This is likely out of date and the file attached to this thread has revisions. It'll be on our Github soon. Regarding this issue you've found, what is the affect? Also, feel free to post any other issues in this thread and we'll take a look.

This isn't a bad idea, disabling the editing of certain fields like names or company names could prevent accounts from being so easily sold to someone else. We'd probably use it internally ourselves.

Blesta 4.2 makes an attempt to determine the correct path to PHP under Settings > System > Automation. Not sure if this helps, but worth taking a look at what is displayed there if running 4.2+

I believe the client will have to do it. If that option was checked when they created their subscription, I believe they can do it within PayPal.. some steps listed at https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/manage_subscriptions/ You can check their subscription in your PayPal account also, and see if you have the option to change it, but I've only ever seen a cancel option.

So only the options in your screenshot? No others? I agree we should do this, but when I create the task I want it to be clearly defined.

I'm not totally sure I understand. Is this just a request to be able to set all of these reseller options on the Package in Blesta, if it's a reseller Package? When the reseller account is set, all these items are passed along? If so, does anyone have a list of all the options that should be included, or a screenshot in WHM where they would be set if created manually?

It's interesting that /dev/urandom is denied, most people that get an open_basedir error do not get one that references this path. You'll want to add this to your open_basedir path, or disable open_basedir.

If it keeps locking up, it's probably encountering an error and crashing. Since it's paid pending services being activated, look at your pending services.. most likely, some are failing to be activated, and possibly using a 3rd party module that is returning an error. Check also module log Tools > Logs > Module. Check also your file log (Settings > System > General > Log directory, open files in directory and look for errors at the same time)

Maybe the fields, like "Option Name" here should be able to be language definitions. If the fields could be translated, do you still think we should add Birthday and Gender? This would allow any fields to be added, and fully translatable. I think this is better than adding the fields into the core. Someone else will ask for SSN, hair color, or whether the person owns a dog, and custom client fields were intended to allow people to add anything they want.

If they were imported properly, then no, you shouldn't have to do anything. You may want to edit a few to spot check them, and ensure they have a username set that matches their cPanel username. If they do, you should be good to go.

Sorry I didn't see this thread sooner. Did you take a look at https://docs.blesta.com/display/user/cPanel#cPanel-ImportingcPanelAccounts ? It describes how to add an existing cPanel account to Blesta. The main thing is that it's pointing to the right server and the username is correct. If so, Blesta should be able to suspend/unsuspend automatically, etc.

Why doesn't a custom client field work for you? For language, you can add your own language definitions to the custom language file and use a definition here for the name instead.

Just because Twitter made a mistake with their logging, doesn't mean that they don't know what they are doing. Twitter has some of the brightest engineers in the world on their team, many of which I'm sure, would disagree with you. Still, how IPBoard operates is outside our control and you should always assume an attacker has your username.

I think you can just convert the fields to hidden, however first_name, last_name, email, username are required. In /plugins/order/views/templates/wizard/signup.pdt for example (your path may vary depending on order form used) search for first_name, and starting there change $this->Form->fieldText to $this->Form->fieldHidden for each field you want to hide.. probably first_name, last_name, company, address1, address2, city, country, state, zip, phone, fax. For the required fields (first_name, last_name), you may want to just prefill some standard info like "Customer" or something. I may have time to play around with and test this, and if I do I'll post code you can use, and update the docs so it may be helpful to others.

It's in progress, thank you for your patience. The first phase, to be included with version 4.3 ASAP, will have everything you need to make it easy to comply with any requests you may receive. If you receive any requests prior to our release of 4.3, let us know and we will help. It's still possible to comply, but is a little more manual.

I would suggest contacting IPBoard about any concern. Most organizations do not have secret usernames.. they force the use of email addresses, or display usernames publicly. Reddit, Twitter to name a couple allow you to login with your display name. I operate under the assumption that an attacker knows my username, but I can see how you'd want that to be secret. Nothing we can do about it though.

Yes, it is very spiderwebby indeed. ? Fortunately the relationship notation can be changed from spiderweb to UML ? I forwarded you Tyson's response to your questions.

So there are 2 versions he can download? Maybe he downloaded the PHP 5.4 one. Yes, the ioncube encoder for PHP 5.6 should work for 7.0.

When creating a package, you can set multiple prices to cover whatever terms you want. When editing the package, click "Add Additional Price" under Pricing. Then for Term, enter 3, for Period select Month, and set your price. You just added a 3 month/Quarterly option.

This was a change that IPBoard made.. after upgrading one day, users were forced to login with display name. Not aware of any account compromises, if you have a decent password, you should be fine, and we block brute force attacks.

I'm helping him setup his Blesta. Do you have a PHP 7.0 compatible version of xtreme_codes module? I get an ioncube error that it is for PHP 5.4, and need to be encoded for PHP 5.6 (which will work on PHP 5.6 and 7.0).

That's weird since your error mentions the path /usr/local/apache/modsecurity-owasp-old/base_rules/modsecurity_crs_41_sql_injection_attacks.conf locate injection_attacks.conf Maybe you'll get a result? If you get a "database" error, unable to search.. yum install mlocate -y updatedb & And try again after a few min.