Jump to content

Paul

Blesta Developers
  • Posts

    6,687
  • Joined

  • Last visited

  • Days Won

    839

Everything posted by Paul

  1. Miiiiiiiiiike Stream101, you are welcome here. I was just thinking this morning about Centova Cast, and plan to dig deeper into the API later today to see what it would take to implement. Not to say that it won't still be a while before it's done, but I hope you'll consider Blesta once it is supported.
  2. And mass mailer and affiliate system are in the lead...
  3. Paul

    Release 3.3.0-B2

    I wouldn't mind having it, if you care to share, for a future "official" importer. We've reverse engineered others without decoding, it's not very difficult, but would save some time. What's shocking is that they think caesar ciphers provide any real security. It's hardly encryption.
  4. Paul

    Release 3.3.0-B2

    Out of curiosity, how do they compute their passwords?
  5. Thanks for the details. I'm curious, how do they route both of those ports? Are they both just part of the same VLAN?
  6. A custom module that either directly queries your Oxwall database, or (preferably) calls Oxwalls API (if they have one) would be your best bet. Blesta handles payments, recurring billing, etc natively. Your only real concern here is the ability to change user roles or any other activity that will need to occur with Oxwall based on the users subscription. For example, suspend their access if they don't pay, cancel their access if they cancel their service, and of course, grant their access when they pay. All of these functions would be done through the module.
  7. Do you have some use-cases / examples of why aggregating ports for billing would be preferable for a situation? It seems like most of the time, especially with colo, billing per-port would be ideal. I suppose if you were selling dedicated servers where the customer doesn't have their own switch and drop, and offered a bandwidth plan for the entire account this would make sense but I'm not sure how prevalent that is.
  8. Paul

    Cannot Use Trial

    So you are up and running now? If you have any trouble, feel free to email sales or PM me.
  9. Paul

    Release 3.3.0-B2

    You're welcome to start one, now is a good time to start a conversation about the domain manager. The goal is to get 3.4 out pretty quickly, and focus on the domain manager for 3.5. A discussion about features and functionality would be good.
  10. If you are in the US, you might look at e-onlinedata. We're actually partnered with them, see http://e-onlinedata.com/blesta/ for details and costs.
  11. Very nice!
  12. Ok guys -- I think this has received enough +1's, thanks! Please see CORE-1428
  13. It's no longer private. Really wish we could have had this one done a long time ago, just not enough demand compared to other features, unfortunately.
  14. Paul

    Release 3.3.0-B2

    Unless there are some major issues discovered (unlikely), final release will be next week.
  15. Hey that's pretty cool. Did you use something like PhoneGap?
  16. I voted
  17. This is on our radar and we are doing some research and planning, but this will not be in development for a little while.
  18. Did that work? Installation should only take a few seconds at the most. If it's taking longer than 30 actual seconds, there may be another issue.
  19. One thing you could do is create an invoice with a future bill date. The invoice will not be delivered to the client until that date, nor will they see it in the client area. You can edit the invoice to add new items as they come up, and on the bill date the invoice will be visible and delivered. I did see that you don't want invoices delivered, in which case you can just set the client group to paper. Invoices will be "queued" under Billing > Print Queue, but you can periodically just mark them printed. If you will have services under their accounts, the above method won't work, but you can always sync service renew dates to a specific day. Prorata can also be used to to this as well, but it works for a specific day of the month, so you can't say that you want everything to renew on January 1st for example, it would be the 1st of each month. EDIT: So, if they order on March 15th, and it's a 1 year term, it will charge them for either March 15 -> April 1, or both March 15 - April 1 and April 1 to April 1 of the following year, depending on your "cutoff" day in the prorata settings. You can bill for x hours of support, but Blesta will not track that support automatically. I'd suggest using a sticky note to track that for each individual customer.
  20. Does anyone here instead prefer a "queue" of suspended service that match the criteria for cancellation with a bulk option to schedule the cancellations for a specific day? ie now, or some future date? I ask because cancelling a service is irreversible and some clients may just need an extra nudge to pay. Personally I'd prefer to see services that have been suspended for X days, even if briefly, and choose to cancel them myself. Thoughts? Too much work, should be automated? Or good idea?
  21. Yeah we've discussed this pretty extensively internally. So that we can get it out, the plugin will probably not yet tie into any third party mailers, however it will have a mechanism to queue and deliver mail systematically. So, if you're sending to a lot of people and leave the page or your browser crashes, it will still complete.
  22. Tyson responded while I was typing, so just to add to what he said -- We carefully consider every core feature, if it doesn't make sense to be part of the core then it's implemented as an extension. Take a look at the Order System and the Support Manager. Both very well used, often necessary major features.. but we understand that other developers may create something that people prefer to use instead. Some future features -- KB, Mass Mailer, Affiliate System.. all of these will be plugins. (The KB will actually be part of the Support Manager plugin) Some features just make sense to be part of the core and forcing them to be extensions when they shouldn't be would fragment the system and de-stabilize the most basic function of Blesta. I ask the following questions when considering a new feature - 1. How widely used will the feature be? 2. How likely is it 3rd party developers will want to roll their own? 3. How basic to billing and client management is the feature, regardless of how many people will use it? Not that we go through a checklist, but this should give you an insight into our thought process. It's usually very apparent to us when something should be part of the core or not.
×
×
  • Create New...