Jump to content

Client Can View The Tabs For Suspended Services


Blesta Addons

Recommended Posts

from this thread , i beleieve this is a bug and not a feature request .

http://www.blesta.com/forums/index.php?/topic/3433-function-getclienttabspackages-returned-array-elements/

simply : the client can manage suspended services .

that should not happen in any case , only admins can manage the suspended services .

the fix is simple, render the getClientTabs if the service is active .

 

EDIT :

 

i have posted a fix for this in this post ,for those won't wait until the blesta staff add thier own fix

Link to comment
Share on other sites

  • 2 months later...

I don't think it's a issue they can't do anything.

You are the only who think that is not issue !!!!

If you provide domains/hosting/vps you will consider it catastrophique bug .

All others soft has this in native . v2.5 also has this function , what is new in v3 to call it this is normal !!!

Link to comment
Share on other sites

You are the only who think that is not issue !!!!

If you provide domains/hosting/vps you will consider it catastrophique bug .

All others soft has this in native . v2.5 also has this function , what is new in v3 to call it this is normal !!!

 

Well I might not be the only one... And unless they can un-suspend themselves or edit it I don't see why you are complaining.

Link to comment
Share on other sites

They can unsuspend = no . this is not our compliant .

They can edit = yes and yes . this is our compliant .

A sample case . if a vps is suspended . normally is shutdown in the node , the client can start it from the action tab .

Another case

Domain is suspended , the client can change dns, contacts, get EPP code , remove the lock ...

So what is the meaning of suspended here !?!?

Link to comment
Share on other sites

They can unsuspend = no . this is not our compliant .

They can edit = yes and yes . this is our compliant .

A sample case . if a vps is suspended . normally is shutdown in the node , the client can start it from the action tab .

Another case

Domain is suspended , the client can change dna, contacts, get EPP code , remove the lock ...

So what is the meaning of suspended here !?!?

 

If they can start it that's a issue with the module nothing to do with the tab. If you suspend a license (with Blesta) if they did it, we can't just re-issue it or re-use it.

Link to comment
Share on other sites

The probleme is not what the module do. The problem here is the tabs and contents when the service is suspended or in pending status .

Suspend services = block clients from getting/seeing/making action to the tabs.

So I will assume all the other software including blesta v2 are doing the wrong thing . and blesta v3 has the correct thing that should be in this case .

Even if small plugins in WP and joomla has this feature !!!!

If you use a module that is not related to this bug , or you think is a module issue . I need to open thread for almost all modules shipped with blesta that are concerned for this bug (plesk. cPanel . directadmin. Proxmox. Solusvm . vpsnet . BuyCPanel ....).

I'm still waiting the blesta staff for his point of view .

Link to comment
Share on other sites

  • 1 month later...

Can anyone think of a use case where you would want to allow management abilities of any kind to a client whos service is suspended? Either we have to add a setting to add backwards compatibility, or we implement a fix similar to what has been suggested. If we add a setting, modules could render or not render management views depending on the service status.

Link to comment
Share on other sites

Can anyone think of a use case where you would want to allow management abilities of any kind to a client whos service is suspended? Either we have to add a setting to add backwards compatibility, or we implement a fix similar to what has been suggested. If we add a setting, modules could render or not render management views depending on the service status.

 

 

@Paul :

No, never :)

Suspended = Suspended, so we dont want them to do anything :P (ofcourse only pay late invoices lol)

 

@Naja7host:

I did not tested yet, did you try to edit also in "Cancelled" satus or any outher status not = "Active" ? or is only afetting "Suspended"?

Link to comment
Share on other sites

@Naja7host:

I did not tested yet, did you try to edit also in "Cancelled" satus or any outher status not = "Active" ? or is only afetting "Suspended"?

my code is checking the date_suspended field is empty or not , so basically canceled service i think can access direct url ... i will try it now .

EDIT : i have tested , canceled services, the client can view the tabs by direct urls , so this is not a good sceanario .

@Paul , if the service has status rather than active , the client didn't and shouldn't see anything .

Link to comment
Share on other sites

Can anyone think of a use case where you would want to allow management abilities of any kind to a client whos service is suspended? Either we have to add a setting to add backwards compatibility, or we implement a fix similar to what has been suggested. If we add a setting, modules could render or not render management views depending on the service status.

 

I don't think that there will be any case where showing them would be useful (it might not be an issue to non-hosting businesses like me and LicenseCart) but for hosting providers i think it is critical, when the service status is not active, the only thing i would want a client to be able to access is the service information page, but other tabs should not be there in the first place.

Link to comment
Share on other sites

Modules can display anything they'd like to display, and can choose to not show certain tabs based on service status if they like. Just because you're unable to think of a case where one might want to show tabs for suspended services does not mean there could not be one. I can imagine modules showing tabs for displaying alternate or advanced information particular to that module irrespective of service status. Perhaps they may even allow additional module actions to be performed by the client that are specific to suspended services, for instance, to allow the client to perform necessary pre-unsuspension updates to their service through the module prior to being able to unsuspend the service. This would no longer be possible if tabs are always removed for non-active services, and would prove to be a limitation of the module system in those cases.

Link to comment
Share on other sites

yes to Tyson,

 

But it's like to make very particular/exeptionnal rules a generality,

when generality regarding hosting business is more to hidde, not allow access to technical service's actions (server, update, etc...), but ok to display general info tab.

 

It's ever that way whmcs work.

 

People that want particular display could create their own tab, customization, but the generality of our business should be "satisfied" by default?

Link to comment
Share on other sites

Modules can display anything they'd like to display, and can choose to not show certain tabs based on service status if they like. Just because you're unable to think of a case where one might want to show tabs for suspended services does not mean there could not be one. I can imagine modules showing tabs for displaying alternate or advanced information particular to that module irrespective of service status. Perhaps they may even allow additional module actions to be performed by the client that are specific to suspended services, for instance, to allow the client to perform necessary pre-unsuspension updates to their service through the module prior to being able to unsuspend the service. This would no longer be possible if tabs are always removed for non-active services, and would prove to be a limitation of the module system in those cases.

i respect your idea of reasoning , but i push our idea's is the better one .

service suspension = client can't access/do anything in tabs .

the middle solution between our idea and yours idea , is to create a new tabs like 'xxxxx_suspend' or 'xxxxx_pending', so any tabs that has suffix "_suspend" can be shown in suspend mode , and any tabs has suffix "_pending can be shown in pending status .

is this a workable solution ?

in the END , what we need in case of suspension/canceled/pending status no access to normal tabs .

@tyson, if we take your idea , you "blesta" should update all the core modules , because they have this issue . they never check if the service is suspended or not , and it shown in all status .

Link to comment
Share on other sites

I have created CORE-1570 that suggests we disable client access to module management tabs for suspended services. While an argument exists that modules may wish to provide management features for suspended services, no such example exists. In all known cases, displaying the tabs can have negative consequences. The evidence is, at this time, overwhelmingly in favor of not displaying module tabs to clients for suspended services.

 

If at such time a case can be made for modules rendering management features for suspended services, then it would make sense to address that at that time.

 

Thanks for the feedback! 

Link to comment
Share on other sites

Modules can display anything they'd like to display, and can choose to not show certain tabs based on service status if they like. Just because you're unable to think of a case where one might want to show tabs for suspended services does not mean there could not be one. I can imagine modules showing tabs for displaying alternate or advanced information particular to that module irrespective of service status. Perhaps they may even allow additional module actions to be performed by the client that are specific to suspended services, for instance, to allow the client to perform necessary pre-unsuspension updates to their service through the module prior to being able to unsuspend the service. This would no longer be possible if tabs are always removed for non-active services, and would prove to be a limitation of the module system in those cases.

 

1- That would require additional effort to be put in to accomplish this since the "getClientTabs($package)" method does not have the access to $service object, which means i will need to access the database directly to check the service status, while any tabs method (e.g actionTab method) have the access to the $service object where we can check the service status from the module, the tabs links will still be shown on the sidebar.

 

2- The case you mentioned is a special/odd case, and although Blesta might be used by many non-hosting providers where this would not be an issue at all but an advantage, Blesta's main targeted clients are hosting providers, and in the hosting industry this is very uncommon.

Link to comment
Share on other sites

i respect your idea of reasoning , but i push our idea's is the better one .

service suspension = client can't access/do anything in tabs .

the middle solution between our idea and yours idea , is to create a new tabs like 'xxxxx_suspend' or 'xxxxx_pending', so any tabs that has suffix "_suspend" can be shown in suspend mode , and any tabs has suffix "_pending can be shown in pending status .

is this a workable solution ?

in the END , what we need in case of suspension/canceled/pending status no access to normal tabs .

@tyson, if we take your idea , you "blesta" should update all the core modules , because they have this issue . they never check if the service is suspended or not , and it shown in all status .

 

Adding support for tabs with suffixes for service statuses is too specific. The idea here is to create a more general solution that is flexible to all use cases regardless of specific (e.g. hosting) module platforms. I describe this more below..

 

 

While an argument exists that modules may wish to provide management features for suspended services, no such example exists. In all known cases, displaying the tabs can have negative consequences. The evidence is, at this time, overwhelmingly in favor of not displaying module tabs to clients for suspended services.

 

If at such time a case can be made for modules rendering management features for suspended services, then it would make sense to address that at that time.

 

I have given examples of cases where modules may want to display tabs for services of a specific status to accommodate its designed functionality. A specific example of an existing module does not need to be given, however, ignoring the possibility would be a hasty generalization.

 

 

1- That would require additional effort to be put in to accomplish this since the "getClientTabs($package)" method does not have the access to $service object, which means i will need to access the database directly to check the service status, while any tabs method (e.g actionTab method) have the access to the $service object where we can check the service status from the module, the tabs links will still be shown on the sidebar.

 

Whether additional effort needs to be added to modules to accommodate this behavior is determined by how flexible we decide such a solution to be implemented. For example, we could add a setting into Blesta that you can check to allow module tabs to be shown, or to hide them. Blesta would handle this independently of the module, and so no module would need to be updated to behave this way.

 

If we wanted to be much more flexible to the module system, we could add support for a module method whereby the module verifies a tab's use. If a module supports three tabs, but only one should be displayed when the service is suspended, then Blesta can call a method on the module to ask it whether that given tab should be displayed/accessed, and pass in any variables (service, client, package, etc.) that the module may need to make that distinction. In this case, the modules would could be updated to include this behavior, or we could default the behavior to hiding all tabs anyway.

 

 

2- The case you mentioned is a special/odd case, and although Blesta might be used by many non-hosting providers where this would not be an issue at all but an advantage, Blesta's main targeted clients are hosting providers, and in the hosting industry this is very uncommon.

 

The case may be rarely used, but it is nontheless valid. Not considering such cases would be restrictive to those that would use it otherwise. I agree many hosting providers use Blesta, however, the software is not tailored only, and very specifically, to hosting providers. The module system is not a hosting module system, but a general module system, and I think it's reasonable to generalize solutions to accommodate as many users/companies/industries as possible.

 

 

The main point I'm making is that we shouldn't create a potentially restrictive solution (for some) to a problem when we can make it more open, flexible, and general purpose (for everyone).

Link to comment
Share on other sites

I have given examples of cases where modules may want to display tabs for services of a specific status to accommodate its designed functionality. A specific example of an existing module does not need to be given, however, ignoring the possibility would be a hasty generalization.

  

Whether additional effort needs to be added to modules to accommodate this behavior is determined by how flexible we decide such a solution to be implemented. For example, we could add a setting into Blesta that you can check to allow module tabs to be shown, or to hide them. Blesta would handle this independently of the module, and so no module would need to be updated to behave this way.

  

 

The main point I'm making is that we shouldn't create a potentially restrictive solution (for some) to a problem when we can make it more open, flexible, and general purpose (for everyone).

i got your idea , so what i can suggest "with my poor level" is to add some data passed to the tabs like array .

	public function getClientTabs($package) {
		return array(
			'tabClientActions' => array(
						'lang' => Language::_("module.tab_actions", true) ,
						'active' => true, // if not set by default is true
						'suspend' => false , // if not set by default is false
						'pending' => false ,  // if not set by default is false
					) , 
			'tabClientStats' => array(
						'lang' => Language::_("module.tab_actions", true) ,
						'active' => true, // if not set by default is true
						'suspend' => true , // if not set by default is false
						'pending' => false ,  // if not set by default is false
					) , 
			'tabClientConsole' => array(
						'lang' => Language::_("module.tab_actions", true) ,
						'active' => true, // if not set by default is true
						'suspend' => false , // if not set by default is false
						'pending' => false ,  // if not set by default is false
					) 
		);
	}

with like shema we can controle the tabs should be shown in active/suspend/pending status .... if not set in module , use the default config (can be a option setting in blesta ) .
Link to comment
Share on other sites

with like shema we can controle the tabs should be shown in active/suspend/pending status .... if not set in module , use the default config (can be a option setting in blesta ) .

 

Yes, something like what you've described could work. I'm not too concerned over the implementation strategy at the moment, though. Getting the design right is preferred, and then how best to implement that can be determined afterward. We'll have to think about this some more.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...