Rocketz

That's like asking how long a ball of yarn is It depends on the margins of the business. If you're talking purely from a low margin hosting standpoint (most common), it's usually just the first year that's free. If you're talking higher scale, if you order a yearly plan with those companies, the domain is always free. I'm not quite sure how I would code that in. I'm not a coder. But maybe multiple discount codes? One that expires after the first year, and one that's recurring? Then the billing will need to show which line item is being discounted / credited. Sorry, I don't have an easy answer how to implement this. Just sharing what i know within the hosting industry

You hit the nail on the head with your last sentence. No one controls the pricing apart from ICANN and the TLD registries. It's also never been an expectation for customers to be locked into domain pricing. If you really want a workaround to this, businesses can offer a coupon code / discount to bring the price back down. But it should be at their discretion. But in most common scenarios, price increases are passed on in the domain world.

I prefer granularity where possible. There can be scenarios where those addons are more costly, depending on the TLD. It's also possible to have a special promotion to increase the awareness of a TLD, so X addon is free or something. I can't predict the future, but I'd prefer having the option built in if it meant nearly similar work hours are needed to do it, than not. I think the hardest part here is how you merge granularity with an easy to use interface. No one wants to enter pricing information 100 times. Domains are definitely not like other services. At their core, sure, they're just another service. But all the big companies, and 20 years of domain registrations have trained people to see domains as their own type of service, and don't equate them to other types of services. Maybe it's because they're not paid monthly. Who knows. But the common perception is domains should be in their own area. There's a reason big companies also have them separated. Their internal focus groups told them this is the expected behaviour. This part can work the same. No need to re-invent the wheel on this. There's only so many actions you can take with domains, so they don't need a billion email templates. One for every action possible + expiry ones. That should be fine to start Good starting list. When a domain is about to expire, or expire, I'd like a ticket to be created with the customer too. At my old company, there were so many customers that did not understand why their domain expired. We're talking ~10-15 tickets like that daily (we had about 75k registered domains, and we weren't even a domains company). Also, if auto-renew is enabled, it should say that in the expiry notice. Or show that it's not if it's not enabled. There was so much confusion with that. I like this idea. A lot!! It would help the developer community. But please don't make the same mistakes again. Get the 4-5 biggest registrar modules done yourselves, or get one of the fantastic developers here to work with you in tandem, and buy their work and include it into Blesta. I won't tell you how to code or how to collaborate, but it's an idea to get core features people expect into their hands, without delaying development. Developers get paid, Blesta comes with better built-in features. I think you included this with "transfer" but, the ability to send the EPP code to the customer so they can transfer out. That should be part of the module. The rest of what you listed will be okay for 99% of all customers, so good list Backwards compatibility is fantastic. Until it's not By that I mean, when you release something, keeping backwards compatibility is a must-have, or else you're disrupting business. But a way to migrate that data cleanly into the new module would be really really good to have too. Don't let this be a manual process if you can help it. Again, determine which modules people are using the most, work with the developers so a migration path can be planned. There aren't that many for Blesta, so this should be easy enough to figure out. Any feature that's already possible at the single level. ID Protect, Renew, Transfer, Change Whois. others listed No reason to be selective here, the code is probably 95% built for the single functions anyway Of course, when domain prices go up,being able to bulk edit the pricing of a TLD would be nice too, and not have to edit over 30 boxes of prices (10 years, with 3 actions for each line) One neat feature would be you set your cost in Blesta, and then select what your margins are, and Blesta automatically updates everything when you enter a new cost. Thanks! You got what should be good for 99% of most use cases. It's a good starting block. I'm sure there's other little things here and there, but for a first release, this is what I expect for basic functionality. There aren't a million things you can do with domains, so the hard part will be getting everything tied together for billing and automation.

I think you need an attitude adjustment and take some basic business classes. "You make me laugh" doesn't really make me want to discuss anything with you, and others on this forum have had the same opinion of you over and over. I've glossed over it because you do provide a helpful presence in most threads, but you really need to tone it down. Before posting, re-read what you write and edit some of it out. It will do you a world of good. I'll just leave it at this : If people find the module to be worth the money, they'll pay it. If not, the developer will have to look at his options. Complaining about his pricing without any reasoning behind it, is asinine.

I'm not privy to internal details, but from the public facing view, Blesta is barely growing as a market. Even if it is growing quickly, the market for a logic boxes module isn't as wide spread as Blesta itself. Given coders are usually paid well, the time it takes to develop a module, keep the updates going, security patches.. as a developer, I'd prefer a subscription based model. Just look at the Apple App Store, and Google Play, both now allowing subscription based models to emerge. That's what developers want. They want to lock you in, but also subscriptions improve their quality of life. Why do you think it's okay for Blesta to charge for support and updates on a yearly basis + the larger upfront cost, but module developers can't? As far as I'm concerned, if a module is essentially adding core functionality into Blesta, it's the same exact work.

If I were him, I'd charge more. Blesta is a very small market for module developers. They need to be paid adequately for their time. I don't get the complaints about the price

Awesome work!

the only time i've come across a locked domain preventing nameserver changes is with .ca domains on opensrs i think. And that was 10 years ago unless there's something very specific to the TLD, changing nameservers should work fine regardless if a domain is locked or not

It's a workflow issue. When you have a lot of tickets, you want that information right in front of you. Just because there's another way to do it, doesn't mean it can't be improved on I agree with this. At another company, we built our helpdesk to show all tickets from an email address, but the hits to the database started slowing everything down. So we showed only the most recent tickets, and on another page, you could search within a date range. I'm okay with that idea

One feature I'd really like is being able to have a list of previous tickets a customer or email opened. Could be the last 5 tickets, or let us actually select the threshold and database hit we want to take with that kind of feature Could be below the ticket, or a new column on the right side of the support ticket view. With active links and being able to view the ticket ID and subject on that same screen. Can even make it fancy.. on mouse hover, you see the customer's first post to the ticket, or last one. Or the note on the ticket. But before anything fancy, I'd just like the feature to actually be put in place

I'm not sure why a new customer would know all those terms though. To him, it just means the entire area the customer sees. So take it as "everything that can be themed on the client area" as his question Basically : where can he learn about theming everything there is in Blesta, keeping it to the default modules for now. If he wanted to make Blesta look like X competitor for example. Where can he learn to do that? Where's the entire documentation for that?

He means the client area. What the customers see when they log in. In other news, too many sensitive people in the world.

Hmmm maybe that's why. I'm testing this with a second domain, since I can't disrupt emails without knowing everything works first. Here's what i have Domain1.com = blesta install Domain2.com = google apps email domain admin@domain2.com has alias info@domain2.com forwarding to info@domain1.com So any email sent to info@domain2.com which gets forwarded and then piped into info@domain1.com will be rejected, because the original "to" address is info@domain2.com?

yep, same here. This isn't a deal breaker, but more of a workflow issue for my company. Sometimes you need to place a specific customer on a specific server... think for example managed vps where they only have access to the shared account, like a shared hosting customer. The "shared" account needs to be provisioned on the correct vps. Not being able to do that in Blesta adds 5-10 minutes to the actual process. It's easy to work around it, just a PITA

I am using piping But I don't want to have 12 google apps accounts. I want 1. Along with 12 aliases on it. admin@domain.com is the main account. info@, sales@, whatever@ are the aliases. I forward the aliases to the blesta domain. Alias1@google-apps.com forwards to alias1@blesta-install.com, alias2 forwards to alias 2 and so on However, if I sent an email to alias1@google-apps.com, it forwards the email to blesta, my server has logs of it. However, Blesta doesn't pipe in the ticket. It sends the "Ticket Bounce" error message template. So it actually reaches Blesta, but Blesta rejects creating a ticket for it. Departments are set to accept all emails, not just customers. However, if i email alias1@blesta-install.com directly, the ticket is piped in just fine. That's what I want to know. What's going on in Blesta to refuse creating a ticket the first way.

Only reason is SLA's. Up to 5 minutes before a ticket is seen equals up to 50% of the reaction time for certain SLA segments in my case. Piping only takes about 30 seconds to a minute, so that helps a lot when it comes to response and reaction times. If only it were so simple to use IMAP in my case

So I tried to set this up anyway. It's only $10, but I'd like to know WHY it's not working. Here's the setup at Google Apps admin@domain.com is the real email account. Alias is info@domain.com Setup forwarder in admin@domain.com to forward all mail that contains "to: info@domain.com" to email@subdomain.blesta-install.com the mail actually does get to the Blesta install, but always bounces with the Ticket Bounce reply. Saying either the department isn't there, etc However, if I email from Gmail directly to email@subdomain.blesta-install.com - the ticket is created, no errors. Departments are setup to receive email from anyone, not only customers. Using piping, not IMAP or POP3. So I'd like to know what's going on inside Blesta that bounces these emails, instead of creating a ticket.

Before I go ahead and try this, maybe someone knows the answer. My company is transitioning to Google Apps for everyone's emails. Better collaboration tools make it a smart idea But all of our customer facing emails that pipe into Blesta via forwards from another server are on the same domain. We got 12 support departments in Blesta, each with their own email address, something easy like sales@, support@, etc I don't want to setup 12 email accounts at Google, at $10 a piece, just for a forwarding service So what I'd like to know is, can I setup 1 single email account, along with 12 aliases, and then forward each alias'ed email to Blesta's install? Aliases are essentially email forwarders at Google. Not real email accounts, but you can receive email on them and the from address will show the alias email. Will this work?

paul, how did you find the conversion from wordpress to hugo went? Were you able to re-use any elements, or it had to be completely designed from scratch?

And he'd be right to A lot of us are in no man's land when it comes to Blesta. Developers aren't sure everything is going to work. Those of us who paid for custom work aren't sure what we just paid for will actually work when 4.0 hits. Many of us are waiting on features beyond 4.0, which means the longer this release is delayed, the longer the next one is too. And in some cases, adds considerable expense in additional custom development. And it's been delayed a long time. A very long time by most software standards. I posted about my thoughts on this in another thread, how Blesta should be able to pivot faster, and do quick releases of smaller features instead of building out one giant package and releasing it with the bang of a wet noodle. One competitor actually gained market share with this kind of strategy, although he blew it by being completely crazy and unreliable. Browsers like Chrome are at what, version 58 now or something? Quick releases, quick updates are key now. They don't need massive killer features in each release, just small ones that accumulate over time, and while that happens you work on 1-2 larger features that you want to make a splash on. Some releases could contain a new module for example. Or improving existing modules. Say there's demand for X module, you pivot and build it. Split the resources you have accordingly. My 2 canadian cents.

Your host really needs to help you out on this. That error usually happens because your account/domain is set to receive mails on another email server. You're piping to a local email that's set to refuse incoming email.

Ah okay. But there's a bunch of departments. Abuse, sales, alerts, and a few others. There's no way to get those names into the "from" field?

Nothing doing The from field is not parsing any variables at all. The subject field is though. For example : From Field : "Company - {ticket.department_name}" - the variable isn't being parsed But, doing this in the subject field "{ticket.department_name} + others" - the department name shows up just fine. I'm on the latest Blesta. Weird

Default Blesta all around for now. Templates: Ticket Received and Ticket Updated thanks

Hmm that didn't seem to work. I tried "Company - {ticket.department_name}" in the "from name" field. When I received the email, I got, literally, "Company - {ticket.department_name}" - as if the variable wasn't being processed. Thoughts?