Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Failing to type a slice name in the Tenant view's <Create Slice> feature causes a 500 error #113

Open
scottmbaker opened this issue Oct 5, 2015 · 9 comments
Labels

Comments

@scottmbaker
Copy link
Member

No description provided.

@scottmbaker scottmbaker added the bug label Oct 5, 2015
@teone
Copy link
Member

teone commented Oct 6, 2015

I also notice that the UI is not clear about the form of the name you should insert. No suggestion are provided and the form should be validated client-side (for what is possible).

image

The slice name should start with site name plus _ ? In this case I suggest to move site name out of the input

@teone
Copy link
Member

teone commented Oct 13, 2015

I think I found the bug:
the slicePlus custom xosValidate (xos-backbone.js:755 where the name is checked) is never triggered.

How that is meant to work? Should it replace the xosValidate function on line 134?

@scottmbaker
Copy link
Member Author

It looks like my intention was that the xosValidate for sliceplus would override the default xosValidate. It looks like I used the same construct for Slice's xosValidate. I probably intended to extend the syntax of define_model() to support overriding methods, but never finished it. Feel free to fix as you think best.

@teone
Copy link
Member

teone commented Oct 14, 2015

Ok that's exactly what I've done. Tomorrow morning I'll write a test for this and come up with a PR.

@teone
Copy link
Member

teone commented Oct 19, 2015

@sbconsulting I've noticed that an error happen also if a white-space is used in the slice name.

@teone
Copy link
Member

teone commented Jan 19, 2016

@sbconsulting we should consider moving this and the developer view to the new XosLib implementation in AngularJs so that we can easily close this issue. Which is the priority respect other views?

@scottmbaker
Copy link
Member Author

I think redoing the tenant view using the new framework would be a great idea. We should discuss with Larry if there are any other changes we should make to the Tenant View before re-implementing it.

@llpeterson
Copy link
Contributor

If we're talking the current Tenant view, then yes, that should be
relatively high priority.

I think we agree that the admin interface remains as-is for now, but I
wanted to make sure of that.

Larry
On Jan 19, 2016 11:57 AM, "sbconsulting" notifications@github.com wrote:

I think redoing the tenant view using the new framework would be a great
idea. We should discuss with Larry if there are any other changes we should
make to the Tenant View before re-implementing it.


Reply to this email directly or view it on GitHub
#113 (comment).

@teone
Copy link
Member

teone commented Jan 19, 2016

I'll assume that is the same for the Developer View?

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants