interfasys
Verified User
l0rdphi1 said:
Should I understand that I have to recreate all my packages after installing iTron because it doesn't create groups for already present packages (I see nothing in Package Groups)?
[release] Installatron v2.0
- Thread starter l0rdphi1
- Start date
Should I understand that I have to recreate all my packages after installing iTron because it doesn't create groups for already present packages (I see nothing in Package Groups)?
interfasys
Verified User
Just did that. Still nothing in my Package groups.
Also : " http://downloads.phpcoin.com/phpcoin_v121b_full.zip inaccessible"
Also : " http://downloads.phpcoin.com/phpcoin_v121b_full.zip inaccessible"
Can we be sure this box has any DA package groups on it? 
Update: I just noticed iTron is only listing packages that do have users assigned to them through DA. I already have rc5 listing empty groups and plan to release shortly.
Phi1.
Update: I just noticed iTron is only listing packages that do have users assigned to them through DA. I already have rc5 listing empty groups and plan to release shortly.
Phi1.
Last edited:
interfasys
Verified User
This boxes has reseller and user packages and a couple of users using them.
If I login as a user created by admin, installatron gives me "No packages exist."
If I login as a reseller created by admin, installatron gives me "No packages exist."
If I login as a user created by reseller, installatron gives me "No packages exist."
If I login as admin and go to the different levels I can see all the applications when I go to installatron. That's the only login that works.
If I login as a user created by admin, installatron gives me "No packages exist."
If I login as a reseller created by admin, installatron gives me "No packages exist."
If I login as a user created by reseller, installatron gives me "No packages exist."
If I login as admin and go to the different levels I can see all the applications when I go to installatron. That's the only login that works.
interfasys
Verified User
I've just created a new user and installatron shows up in its cp, so here is what I suspect happened. The original packages that the old users chose have been removed and replaced by new ones. That would explain why nothing shows up in their cp.
Now in the package group I see the package that the new user chose and when I go inside, I see the other users as being unassigned.
I see two DA problems. Removing packages that are in use should not be allowed (maybe I used force somewhere?). When showing details about a user, the chosen package should be clearly written somewhere (I see absolutely nothing using the enhanced skin).
Now in the package group I see the package that the new user chose and when I go inside, I see the other users as being unassigned.
I see two DA problems. Removing packages that are in use should not be allowed (maybe I used force somewhere?). When showing details about a user, the chosen package should be clearly written somewhere (I see absolutely nothing using the enhanced skin).
In DA whenever a user is edited from a package's defaults, the user is switched to DA's "custom" package group. This is why users show up in the Unassigned area of an iTron group: the Unassigned box is a list of all users in DA's "custom" group.
Not sure if that answers anything you were after or not.
Phi1.
Not sure if that answers anything you were after or not.
Phi1.
interfasys
Verified User
Since all my users use custom settings, that would explain a lot of things 
How about creating a "custom group" as default for all the refugees?
Or maybe improve the group thing by allowing us to create groups and to assign any users or packages to a group?
How about creating a "custom group" as default for all the refugees?
Or maybe improve the group thing by allowing us to create groups and to assign any users or packages to a group?
interfasys
Verified User
Indeed, I think this technique should work with rc5.
interfasys
Verified User
It's better, but...
I've assigned all users to my custom packages.
I've selected a couple of applications for one of the other package.
I login as a user of this package (non-default) and I see the whole listing, not just the applications that I did chose for that package.
Did I miss something?
I've assigned all users to my custom packages.
I've selected a couple of applications for one of the other package.
I login as a user of this package (non-default) and I see the whole listing, not just the applications that I did chose for that package.
Did I miss something?
interfasys
Verified User
Yes, the difference is that I've modified a non default group. I've left the default one with all the apps.
Where have all my groups gone?
Since the last upgrade of installatron, I have lost all the groups that I have set up.
I had these customised to certain users.
The new method of package groups does not allow me to single out certain users with customised choice of applications.
This is now very difficult because my groups were not set up the same as the hosting package groups.
It would be better to have the ability to add my own groups so that I can at least use it the way I was before. The only problem with the old method was that resellers didn't show up in the list of users.
Please fix this soon.
Since the last upgrade of installatron, I have lost all the groups that I have set up.
I had these customised to certain users.
The new method of package groups does not allow me to single out certain users with customised choice of applications.
This is now very difficult because my groups were not set up the same as the hosting package groups.
It would be better to have the ability to add my own groups so that I can at least use it the way I was before. The only problem with the old method was that resellers didn't show up in the list of users.
Please fix this soon.
Group Name Problem
What happens if more than one reseller decides to use the same hosting package name?
How can we then set up different groups for the different resellers as both will not want the same options for installatron.
A "standard" package may be different for each reseller.
"Standard for one may be a basic package and "Standard" for another may be an advanced package with all the options.
??????????????????
What happens if more than one reseller decides to use the same hosting package name?
How can we then set up different groups for the different resellers as both will not want the same options for installatron.
A "standard" package may be different for each reseller.
"Standard for one may be a basic package and "Standard" for another may be an advanced package with all the options.
??????????????????
Yes, the way that DA does packages makes it very difficult to find an ideal way to handle package groups in Installatron.
The original method was ok on small servers, but it was messy and slow for servers with large numbers of users. The feedback we got was that basing it on DA's packages would be better.
The new method still isn't exactly intuitive, but it's probably slightly easier to use on a typical server than the old one. And I think you can still do what you are wanting to do -- just create a new DA package and assign the user to it. That way you can give that user their own settings.
Looking at it now, I guess that the best approach is entirely dependant on how each individual server is set up. How many users you have, how you differentiate between your user types, what limits you have on your resellers, and what level of control you want over script assignment. Neither approach is ideal for everyone.
Phil just spent 3 days recoding the package groups so he's going to kill me for saying this, but we'll have another think about it and see if we can find a third approach. No promises though.
The original method was ok on small servers, but it was messy and slow for servers with large numbers of users. The feedback we got was that basing it on DA's packages would be better.
The new method still isn't exactly intuitive, but it's probably slightly easier to use on a typical server than the old one. And I think you can still do what you are wanting to do -- just create a new DA package and assign the user to it. That way you can give that user their own settings.
Looking at it now, I guess that the best approach is entirely dependant on how each individual server is set up. How many users you have, how you differentiate between your user types, what limits you have on your resellers, and what level of control you want over script assignment. Neither approach is ideal for everyone.
Phil just spent 3 days recoding the package groups so he's going to kill me for saying this, but we'll have another think about it and see if we can find a third approach.
No promises though.Issue with groups
Hi,
I have pretty much the same concerns as (Theman) with several resellers using the same package names .
I didn’t mind the previous groups organization as it was more flexible (for my needs) apart from resellers not showing up in the list of users.
On the other hand the new way would also be handy if package names were unique through the whole system and if a user was not loosing its original assigned package name as soon as it's modified.
I'm sure there are many reasons for things to be done one way and not an other ... but can someone tell me if the followings would or would not be more flexible ?
- Admin can upgrade as done now, and list all resellers (including admin's reseller) allowing them to have or not the installatron reseller options.
- Resellers (including admin reseller) can set groups of applications and include selected users in a group or an other. Users that are part of no groups don’t have access to installatron.
- User , have access to the group of applications the reseller decided he could have ... or none if part of no group.
Just an idea as I thought it was going more in this direction but it didn’t.
Miky
Hi,
I have pretty much the same concerns as (Theman) with several resellers using the same package names .
I didn’t mind the previous groups organization as it was more flexible (for my needs) apart from resellers not showing up in the list of users.
On the other hand the new way would also be handy if package names were unique through the whole system and if a user was not loosing its original assigned package name as soon as it's modified.
I'm sure there are many reasons for things to be done one way and not an other ... but can someone tell me if the followings would or would not be more flexible ?
- Admin can upgrade as done now, and list all resellers (including admin's reseller) allowing them to have or not the installatron reseller options.
- Resellers (including admin reseller) can set groups of applications and include selected users in a group or an other. Users that are part of no groups don’t have access to installatron.
- User , have access to the group of applications the reseller decided he could have ... or none if part of no group.
Just an idea as I thought it was going more in this direction but it didn’t.
Miky
This crossed my mind as well
How about ...
based on my previous post, since Admin decides which reseller can have Installatron or not, and the reseller then decides of the groups ...
How about the reseller can set 2 types of groups, package-groups and custom-groups. Where custom-groups have priority.
A package-group is a selected choice of applications, a list of the concerned reseller's packages(not already in an other package-group). And an informatve list of users that don't have a valid reseller package assigned to them because they have been modified or other.
So at this point it's pretty much the same as what is currently happening, but at the reseller's level.
Any users that are not handled by a package group are simply listed. So a reseller can if he wants , create other packages and apply them to those users left.
A custom-group is a choice of applications and a list of all users not in other custom-groups. If you want to move a user from a custom group to an other, it needs to be removed from one to be added in an other one. If you want a package-group to apply to a user , it has to be in no custom-groups
At the user level , it could work in this order ...
If the user is part of of a custom-group , he has access to the applications selected in the group and it stops there.
If a user is not part of a custom-group, it is checked against the package-groups. If the user is part of no package groups nor custom groups , no installatron at all.
The more I read it the more I get confused , so i'll stop here, but it sort of made sence when I started to write it. Once again this is just an idea .
Miky
How about ...
based on my previous post, since Admin decides which reseller can have Installatron or not, and the reseller then decides of the groups ...
How about the reseller can set 2 types of groups, package-groups and custom-groups. Where custom-groups have priority.
A package-group is a selected choice of applications, a list of the concerned reseller's packages(not already in an other package-group). And an informatve list of users that don't have a valid reseller package assigned to them because they have been modified or other.
So at this point it's pretty much the same as what is currently happening, but at the reseller's level.
Any users that are not handled by a package group are simply listed. So a reseller can if he wants , create other packages and apply them to those users left.
A custom-group is a choice of applications and a list of all users not in other custom-groups. If you want to move a user from a custom group to an other, it needs to be removed from one to be added in an other one. If you want a package-group to apply to a user , it has to be in no custom-groups
At the user level , it could work in this order ...
If the user is part of of a custom-group , he has access to the applications selected in the group and it stops there.
If a user is not part of a custom-group, it is checked against the package-groups. If the user is part of no package groups nor custom groups , no installatron at all.
The more I read it the more I get confused , so i'll stop here, but it sort of made sence when I started to write it. Once again this is just an idea .
Miky