Leaderboard

You can hit create and set the next due date accordingly and an invoice will automatically be generated on the next cron run. Or you can do it manually as you say. I think it has its uses (I've used it many times on previous installs) and would be a great addition to Blesta.

and add another filed in Invoive table to store client info as array .

Why not add 2 new fields: 1st- On Company, to store next Pro-forma invoice to be generator (this way we always know the next number) 2nd- On Invoive table, to store the old Pro-Forma number, and then display that number in a new colum on Client Invoices listings I think (for what I have tested), is only a couple of lines do be changed on core files, nothing to hard, and it will not interfer with what is alredy made

#1 The way it works currently is that articles without a category assignment are never displayed. Are you suggesting that articles should be displayed on the main KB page where Categories appear, along with Popular Articles? I'm not sure this is something we would want to change. #2 This is related to #3 yes? #3 sounds like a bug almost, I bet the search is not being limited to the language being used.

Yes, or email sales or PM me for a trial key and reference this thread. Since trials are issued via hostnames, and since "localhost" has had a trial before the system will not issue a new trial key for it. Adding a unique hostname to your hosts file per Mike will allow you to get around that. Or, just email sales or PM me and I'll send you one.

A plugin could do this, with built in support with the common modules, cPanel, Interworx, DA, Plesk, etc., at least for central management/overview. However, load/disk/etc monitoring would be best done with something like Zabbix, and that data could be pulled into Blesta for display.

Hello All, i have a custom work to do , but i need your seggestion before i begin , we need to store apps details in tables , but every apps can have new version in the future , so we need when we update a existing app version in apps table , we want to let trace for old versions , like downlods, views, ratings .... the apps table will have a ID for each app, this id si AUTOINCREMENT , also the app name is unique so we can't add the same app twice in the apps table . i know we can need to use two table "apps" and "data" , one for apps , and other for data (downs, views, rates) ... in this case if we have 4 app , we will have 4 rows in data , when we release new version of 2 apps, we still have 4 rows in apps table , and we will have 6 rows in "data" table . this is a good structure or thier is a other structure methode that i should use ? what is your suggested shema for this ?

Since you want stats available for each version, I might revise it to: `applications` id, name, current_version, attr1, attr2, attr3, ..., attrn `versions` version_id, application_id, version, date, views, downloads `version_ratings` version_id, rating, count Depending on how your ratings will be setup, you might change that, but I was assuming something like a 5-star rating. So each version would have 5 records, one for each rating, and each time someone gave it that rating, you increment count on that record.

thanks tyson , but your shema has a limitation , the count views, downloads , rating will be for the app and not for every version , also i have forget to say that the application table should have app name and app version . what i will do is something like : `applications` id, name, version , attr1, attr2, attr3, ..., attrn `application_versions` application_id, version, date, number_views, number_downloads `application_ratings` application_id, rating

I've created a task for us to look into this in CORE-1639.

Not sure, but the module itself doesn't have a list I just wanted a dropdown box instead of a text area.