freenode / gms Goto Github PK

A registration already pending shouldn't disallow someone else from filing. But because this is freenode, let's leave this for last as much as possible then do it on a branch so we can switch from one mode to the other every other day.

When I register a group, I see that the "small blurb" field is shown even if I don't want to add it to public group listing.

The submit button is stuck in the very bottom, which feels wrong

Note: please look in the ui branch for this issue

With simple browser console skills one can edit the HTML for the dropdown list and change the group type to an arbitrary string. This crashes the web frontend whenever the group type is to be displayed. It also results in an arbitrary string being passed to XMLRPC but fortunately it is too dumb to copy newlines into command arguments, preventing GMSServ from emitting arbitrary commands into the services->ircd link.

For v2, we need to rewrite crappy javascripty bits with angular

When registering a group, the help for namespace is actually the one for the url

Note: please look at the 'ui' branch for this issue.

23:53 < *spb> (on that note, gms should probably have a function to display the nickserv info for any given contact's account)
23:54 < *spb> as in, a mouseover of the requesting contact's name to display the literal output of /ns info
23:55 < *spb> i'd probably make it do the info under the account of the logged in user
23:55 < *spb> just to make sure it doesn't leak info that way

10:15 < *jayne> #1) why do we say "group's address, if applicable" then refuse the submission if there is no address or no city? That seems to contradict the "... if applicable"
10:17 < *jayne> #2) Even after entering an address, it says "If the group has its own address, then a valid address must be specified" ... but I did specify an address. (Once I fill in a telephone number, the address error goes away)

The /group/#/view page doesn't include an 'Edit Group Information' link if the group is in pending state, as if implying that one shouldn't be allowed to do that. However one can still manually navigate to /group/#/edit and request a change, and such a change will work fine if approved.

• Approving stuff is now completely broken, design wise

Note: please look in the ui branch for this issue

When editing namespaces:

If there are pending namespaces, it looks ugly:

Note: please look in the ui branch for this issue

We can just add it back to the .tt file

(Note: please look at the ui - changes branch for this issue. )

in root/src/group/cloak.tt duplicated ids in html,
it also affects the javascript linked to it.

See #14

Problem

When using a dotted cloak namespace in the assign to user page, it systematically fails with:

The following errors were encountered:
     - The cloak contains invalid characters.

How to reproduce:

Ask and validate a cloak namespace containing a dot for a group.
Go to "Assign a user a group cloak." type valid input and select the dotted namespace, submit.

Notes:

14:56 you have to check the cloak part for validity on its own
14:57 lets pass on the namespace name and cloak to the request schema object, and then after they're valid, THEN join them "$namespace/$cloak"
14:57 and not pass on that joined string

In group info, the verification info is shown but we should at least explain that the DNS should be a CNAME

The GC of a group should be able to drop a cloak change request (for typos etc) without telling the user or a staffer to reject the request.

A GC can attempt to transfer a channel to any account, and when doing so they will be asked to confirm whether that is indeed the right user:

Please confirm that this is the user that you think it is:

Information on moo (account moo):
Registered : Jan 02 12:07:16 2016 (1d 10h 16m 3s ago)
Entity ID  : AAAAAAAAE
Last addr  : ~mniip@meep/meep
Real addr  : [email protected]
Last seen  : Jan 02 12:07:16 2016 (1d 10h 16m 3s ago)
User seen  : Jan 02 12:07:30 2016 (1d 10h 15m 49s ago)
Nicks      : moo
Email      : [email protected] (hidden)
Flags      : HideMail
Channels   : 0 founder, 0 other
moo was MARKED by mniip on Jan 03 22:29:58 2016 (goes moo)
*** End of Info ***

Doesn't this information seem a bit excessive? Every GC is basically given an equivalent of user:auspex.

When running ~/gms/bin/createdb.pl

{UNKNOWN}: Can't locate Text/Glob.pm in @inc (@inc contains: /home/nick/gms/bin/../lib /opt/gms/deps/lib/perl5/i486-linux-gnu-thread-multi-64int /opt/gms/deps/lib/perl5 /home/nick/perl5/lib/perl5/i486-linux-gnu-thread-multi-64int /home/nick/perl5/lib/perl5 /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /home/nick/gms/bin/../lib/GMS/Schema/Result/ChannelRequest.pm line 212.
BEGIN failed--compilation aborted at /home/nick/gms/bin/../lib/GMS/Schema/Result/ChannelRequest.pm line 212.
Compilation failed in require at /opt/gms/deps/lib/perl5/Class/C3/Componentised.pm line 150. at /opt/gms/deps/lib/perl5/Class/C3/Componentised.pm line 155
Compilation failed in require at ./bin/createdb.pl line 9.
BEGIN failed--compilation aborted at ./bin/createdb.pl line 9.

Right now, it looks different:

20:43 < *decontamin4t0R> i have one user assigned a cloak with gov// by gms... should that be possible? (locally)
20:44 < *decontamin4t0R> ive put a cloak change request with a sub-cloak /...

group/1/take_over the submit button doesn't follow bootstrap style ( class missed )

"TypeError: e is undefined" shows up when typing a channel name to take over. (maybe only when the name isn't in the array)?
Needs investigating

For version 2, we want a JSONy API.

If this thing is released within the life time of the current universe, it may not be a good idea for our migration strategy to be "drop database and recreate".
On the other hand, it certainly helps combat the issues that may arise due to having a large database.

In listing the group's current channels:
The problem seems to be too much margin after the headings:

Note: please look in the ui branch for this issue

10:24 < *jayne> once a group is rejected, what happens to it? It seems to be gone completely, with no way to check its status anymore, to update+resumbit, appeal, or whatever. It's just completely gone with no record of anything ever having happened.

We need this so the request is invalidated if it points to a deleted namespace. NB all insert calls in code will have to be updated, as well as text fixtures, and everything will need to be tested thoroughly to make sure errything is still good.

Also after this we'll hopefully be able to show pending requests, that is if it doesn't set the whole project on fire.

As for invalidating requests I'd say to just make a ResultSet that searches only the requests whose namespace isn't deleted and use that, again we'll have to be vewy vewy careful..

KABOOM!!

Right now we go back to group we just got invited to, which is very confusing especially since you can't view the group until the staff approve you as a GC.

Although I'm not sure if this should be done in GMS or atheme, at some point we may want to look into rate-limiting login requests to prevent abuse...

01:09 < *jayne> errietta: since it's for us anyway, can you add a "See http://www.freenode.net/whatever-thing-about-gms-or-channel-naming.html" to the end of the no-#-for-u error
message?

When transfering the channel to an arbitary account
I think we should pull the 'private' check and do an /ns info from the current user's account, which we'll also need elsewhere

It should be aligned with the rest of the text

Note: please look in the ui branch for this issue

Note: please look at the 'ui' branch for this issue.

We shouldn't force lots of admin clicks if there's nothing to do

Entities that have Change objects should mirror the active change status on the entity itself, so that we stop doing complicated SQL

There is a select box to search on cloaks,
That doesn't work and always search on namespace,
or the error message is incorrect :

Unable to find any namespaces that match your search criteria. Please try again.

11:01 < *jayne> #6) Minor, but after making an edit through admin/group/##/edit, it goes to admin/group/##/edit/submit and says "go back to staff page" but since it's admin/, it should go back to admin page, not staff page

although it's good enough for predictable html it's.. incredibly ugly 👎

%group_id should be automatically changed with js magic.

Rather than having them on errietta.me, they should really be added here.

It would be nice to either move the code here or ask GitHub to setup an official mirror in this repo. I work on some projects that would like to see group registration reopen, so maybe this would encourage people to fork and commit.

This should probably be a tooltip.

The text should be something like:

Submitted: The group has been submitted and is pending verification.
pending_web: The group is pending manual staff verification and approval.
Verified: The group has been verified and is pending staff approval.
pending_auto: The group has been verified and is pending staff approval.
pending_staff: The group is pending manual staff verification and approval.
Active: The group is active.
Deleted: The group has been deleted.

When registering a new group, I have no text field where I could explain my role with the project.

23:43 < *spb> i don't like the way the group and target information is much smaller than the namespace information
23:43 < *spb> particularly on the channel takeover requests

23:47 < spb> also, channel namespaces
23:48 < *spb> should be more clear that they're requesting #asdf- instead of just #asdf
23:49 < spb> but the UI isn't clear that that means that 'test' is requesting #asda-
23:49 < erry> that covers #namespace and #namespace-*
23:49 < erry> always
23:49 < *spb> yes
23:49 < *spb> which you and i know
23:49 < *spb> but isn't obvious to a user or staffer that isn't you or i
23:51 < *spb> more generally, in a namespace request, the most important information is probably the group URL and the namespace in an idiot-readable form
23:52 < *spb> remember that these changes will probably be approved by staff who don't have an encyclopaedic knowledge of every group that's ever registered
23:52 < *spb> so the information that's most likely to influence their approval decision has to be presented right there for them

When I request a cloak change as a GC and a services operator uses /ns vhost to add that cloak, the cloak is listed under both "Active cloaks" and "Requested cloaks".