More modals needed for confirmation #261

Martii · 2014-07-13T04:41:33Z

Currently when sending something to the graveyard we aren't giving an option to cancel/close. Also setting the "Reason" why... it would be helpful to have a modal popup, similar to Delete Script, to enter in the reason.

We do currently have allocated in the DB a space for this but we aren't utilizing it.

Flagging could also have a reason stored but I don't currently see that capability already.

Progress

Basic modals on User and Script removal
Reason in modals (See also More modals needed for confirmation #261 (comment))
Default reasons datalist (See More modals needed for confirmation #261 (comment) and useful to narrow results for Removed items aren't fully searchable #490)

sizzlemctwizzle · 2014-07-13T04:54:00Z

The flag reason should be optional, where as reason for removal should be
required, but obviously cascading removal (e.g. you remove a user and all
that user's scripts get removed as well) should automatically set an
appropriate reason.

Applies to OpenUserJS#261

Martii · 2014-07-13T05:58:46Z

Here's the beginnings... I'm not ready to take this on just yet as an Assignee because I really don't have a clue how to get this part working with the existing remove.js controller.

What am I clearly missing (that's probably staring right in my face) ?? :)

…ther modal we have. Applies to OpenUserJS#261

Martii · 2014-07-13T06:38:27Z

should automatically set an appropriate reason.

I am not quite sure any computer code is that self-aware... usually it's obfuscated code... sometimes it might be undocumented auto liking... e.g. "let's like my fave FB groups in the background without telling you"... I still believe in giving one chance, currently, to not make the same mistake with publishing a script... although there are times that I'd rather not spend a great deal of time being more than fair... but until some more support structure is added to our admin/moderator tasks I think it's best to be a little less stringent until we have most of it all in place.

I took your suggestions and I'm still getting a 404... as this is the 2nd time (yes that's two) that I've twiddled with POST requests... once was on a site that didn't use application/x-www-form-urlencoded... I'm still a bit green outside of xhr's and could use some brief training/pointing out what I've done incorrectly.

* Put in an app_route POST to the specific controller method * Put in a placeholder controller method * Send `enctype` since this will eventually be in there.

* Put in an app_route POST to the specific controller method * Put in a placeholder controller method * Send `enctype` since this will eventually be in there. Applies to OpenUserJS#261

* Add text input box... `Close` button in all modals seems redundant since there are two other ways to close it... click the `&times` or click anywhere outside the modal box... but leaving in for now for some symmetry. * Reorder hidden field to be outside of the form grouping Applies to OpenUserJS#261

Martii · 2014-07-13T09:20:33Z

Lovely... my test account on dev is removed now... ~~Would someone who knows how to do that restore my alter ego on dev (Martii) please so I can continue with my any testing ~~on this~~?~~ This is a very good reason to have this modal'ed so things like this don't happen. ;) ... or instruct me explicitly on how to do it?

And part of the "Remove User" is in modelParser.js.... this isn't consistent... I'm done twiddling with this part of the issue... if anyone wishes to finish it up I'd be very grateful and probably cletusc too. It's on my branch on my fork... just create your own branch, add a remote of me, fetch from me, then merge into your branch...or use your own code. I'll observe on everything I did and/or didn't do correctly... just be nice and don't abstract it too much in one huge commit please esp. one that runs over the whole issues spectrum... otherwise I'm not going to be much use to OUJS in the medium term. Thanks.

Applies to OpenUserJS#261

Martii · 2014-07-13T21:16:17Z

That's pretty much all that I can think of... I don't know how to import the current type with a POST route, and Remove User isn't captured properly, and of course the code for actual removal of a Remove Script and Remove Library is also incomplete.

Any takers/helpers? I can't test without removing an account on dev and being able to restore it after failure in testing.

sizzlemctwizzle · 2014-07-13T21:20:35Z

I'll be taking over the problems you've been having with #262. We'll leave this issue for when I get around to adding a "Reason" for removal and flagging.

* Convert to a post route reusing same handler in controller * Create and include `userModals.html` * Use HTML entity instead of `x` * Change *font-awesome* icon for removal to ban icon for a better visual cue between delete *(trash)* and removal *(Graveyard)* * Very minimal change and mostly *(99.99%)* UI views interaction for removal... yes it does graze [OpenUserJS#262 section block](OpenUserJS#262 (comment)) however this has been needed for current mods and up... Making it a very small change and is why it isn't complete with the "reason" here. Applies to OpenUserJS#261

* One reserved phrase of "User removed" *(any casing)* for automatic content removal when a User is removed. * Basic error checking... Moderators and above should be concise. * Abandoning previous UI since portable devices would barely show the input box... plus a few things have changed since initial attempt. * Leaving out the data list for now until it can be decided where to physically put and name it *(them?)* in the project tree... perhaps time for a user.js. Applies to OpenUserJS#261

* Add a more useful status code/message for missing header instead of default * Some STYLEGUIDE.md conformance with line breaks, white-space and informative comments Applies to OpenUserJS#261 *(Temporary OpenUserJS#262 section block bypass approved by sizzle)*

Martii · 2015-01-10T18:56:58Z

There are currently a few possibilities to get this particular issue closed:

Do nothing with the datalist and let a user.js handle this on a per Moderator and up basis. (e.g. "carefree" but more burden on Script Author and usually much bigger source)
Add the datalist into the scriptModals.hmtl and userModals.html ... this could help prospective Moderators and up to standardize on nomenclature, less typing, and easily searchable/sortable but also increases that particular modal view. (potentially edited a bit for a while too)
Add the datalist into a json and read in dynamically... this presents the issue of file naming and where to put the .json file. If this is done please mention the file name structure and where. This could also help prospective Moderators and up to standardize on nomenclature, less typing, and easily searchable/sortable.
Something else?

Opening up to needs discussion to put in others 2 cents. Please note if I don't get a response I may end up deciding on what to do here. e.g. this is a pseudo poll and timing is short. Thanks.

sizzlemctwizzle · 2015-01-11T02:20:57Z

I like 3 the best, but 2 seems easier to get up and running. My suggestion is to start with 2 and eventually use 3.

Martii · 2015-01-11T08:09:02Z

Agreed on 3... I finished 2 a little while ago and refinished 3 in separate commits. With that process that helped me figure out where the "optimum" placement of the .json files should go I think plus an epiphany on it's structure/inclusion too. :) Thanks @sizzlemctwizzle

Publishing PR shortly.

…emoval * This is a "getting started" list * The text box is free form text input so if a preexisting reason isn't available type one in. * Moderators and up should specify specifics when possible e.g. "Obfuscated code packer/packed" * Currently the datalists are alphabetized instead of priority... ones reason priorities may be different than anothers so please keep it that way. :) **NOTES**: * The trailing space in the value **is intentional** and should be maintained... the reason will be trimmed on submission thus saving some typing * If anyone is wondering why the `option` tag doesn't have a close tag it's due to [the spec](http://www.w3.org/TR/html-markup/option.html) under [Tag ommision](http://www.w3.org/TR/html-markup/option.html#option-tags) * Accessing the datalist should be accomplished by two single clicks *(currently one to focus and one to activate)* with a pointing device, pressing the space bar when nothing has been previously entered, and of course if you already know it just start typing the first part and it should filter the datalist. * When possibly adding new values try to mirror them into whichever modal datalist with/without a plural value e.g. a repeat offender so usually that User will go away... this won't always be the case and it may eventually veer from this structure a bit. * *Try not to abuse* a generic reason without elaborating e.g. like spamming. * I don't consider "silly scripts" to be a valid reason and neither should anyone else. Remember the "Have fun but at the same time not at some other persons expense." part of the TOS. :) * This is option 2 Applies to OpenUserJS#261

Martii · 2015-01-11T08:19:37Z

Heh... GH currently has the commit references backwards sometimes. :\ ... okay in the PR though.

* Minor glitch perhaps down the line Applies to OpenUserJS#261

* One of many CSS fixes again just as in OpenUserJS#268 via OpenUserJS#265 * Reuse the same width... appears well and opens up the Reason to be the focal point Also applies to OpenUserJS#261

* Useful to see if we are doing things correctly on removal * Some STYLEGUIDE.md conformance with braces... manually done Applies to OpenUserJS#261

* Done previously in OpenUserJS#654 for public sortings * Add some *font-awesome* icons to the graveyard * Transform "All Types" to the correct nomenclature of "Clear Filters" * Change `href` to use parent plus `/removed` e.g. `./removed` static * Made User removal reason virtual instead of hard-coded... useful for Search filters e.g. reason is now blank when system generated... still don't allow a blank reason from a real author.. post fix for OpenUserJS#261 and pull OpenUserJS#513. This allows no reserved phrases other than string empty. * Some STYLEGUIDE.md conformance * DB remove model **migrated** as far back as "User removed" existed * Added some common needed Filters and reordered similar to GH... not all are implemented yet Closes OpenUserJS#526

* Change route to use regex and a POST... removed TODO note on it... **NOTE** `nav-pills` UI issue with form buttons... so making `Flag` and `Unflag` in their own div tag as intended * Establish a controller function to flag/unflag * Removed now dead code... aOptions and exports * Cleaned up remove controller function code a little bit to be more symmetrical... post OpenUserJS#510, OpenUserJS#513, OpenUserJS#514 with parent of OpenUserJS#261 e.g. e0929ca...e1e3f7e excluding OpenUserJS#511 * Some STYLEGUIDE.md conformance * Don't `return` some assumed `undefined`s in `aNext()`s and `statusCodePage()` Applies to OpenUserJS#775

* for possible common reason for removal. Applies to OpenUserJS#519 and OpenUserJS#261 and OpenUserJS#261 (comment) and

Martii added enhancement labels Jul 13, 2014

Martii pushed a commit to Martii/OpenUserJS.org that referenced this issue Jul 13, 2014

Twiddling with adding a prompt to remove script

fc10866

Applies to OpenUserJS#261

Martii pushed a commit to Martii/OpenUserJS.org that referenced this issue Jul 13, 2014

Remove the trashcan font icon... not currently symmetrical with the o…

71996a0

…ther modal we have. Applies to OpenUserJS#261

Martii added the needs discussion label Jul 13, 2014

Martii referenced this issue in Martii/OpenUserJS.org Jul 13, 2014

More twiddling for modal confirmation

8447d93

* Put in an app_route POST to the specific controller method * Put in a placeholder controller method * Send `enctype` since this will eventually be in there.

Martii pushed a commit to Martii/OpenUserJS.org that referenced this issue Jul 13, 2014

Add in a datalist to the UI for common reasons... **INCOMPLETE**

47c8b0e

Applies to OpenUserJS#261

Martii assigned sizzlemctwizzle and unassigned sizzlemctwizzle Jul 13, 2014

Martii added the sooner label Jul 16, 2014

Martii mentioned this issue Jul 26, 2014

Finish off Acceptable Licensing header #278

Merged

Martii mentioned this issue Dec 6, 2014

Better Moderation Tools #485

Open

8 tasks

Martii added this to the #485 milestone Dec 6, 2014

Martii self-assigned this Jan 8, 2015

Martii removed the needs discussion Blah, blah, blah, wahh, wahh, wahh, etc. label Jan 8, 2015

Martii mentioned this issue Jan 9, 2015

Add missing basic modals for user/script removal #510

Merged

Martii mentioned this issue Jan 10, 2015

Support existing incompleted "reason" value for remove user and script #513

Merged

Martii mentioned this issue Jan 10, 2015

Process remove with form data asynchronously #514

Merged

Martii added the needs discussion Blah, blah, blah, wahh, wahh, wahh, etc. label Jan 10, 2015

Martii removed the needs discussion Blah, blah, blah, wahh, wahh, wahh, etc. label Jan 11, 2015

Martii mentioned this issue Jan 11, 2015

Issue 261 data list #519

Merged

Martii pushed a commit to Martii/OpenUserJS.org that referenced this issue Jan 11, 2015

Place closing option tag inside conditional

3660049

* Minor glitch perhaps down the line Applies to OpenUserJS#261

Martii closed this as completed in 25dc49f Jan 12, 2015

Martii removed their assignment Jan 12, 2015

Martii removed the sooner Sooner would be appreciated. label Jan 12, 2015

Martii mentioned this issue Jan 12, 2015

Limit Item in Graveyard to fixed width #524

Merged

Martii mentioned this issue Jan 12, 2015

Linkify type column in the Graveyard to the model content #525

Merged

Martii mentioned this issue Aug 4, 2015

Apply sort parm to URI for Graveyard #699

Merged

Martii mentioned this issue Oct 22, 2015

Modify view and controller to allow setting of a fixed reason when flagging #775

Closed

Martii added the CODE Some other Code related issue and it should clearly describe what it is affecting in a comment. label Oct 26, 2015

Martii mentioned this issue Oct 26, 2015

Added reason to any current flagging with a *bootstrap* modal #783

Merged

Martii pushed a commit to Martii/OpenUserJS.org that referenced this issue Mar 12, 2016

Add undocumented auto-gifting(s) to the json

7d35139

* for possible common reason for removal. Applies to OpenUserJS#519 and OpenUserJS#261 and OpenUserJS#261 (comment) and

Martii mentioned this issue Mar 12, 2016

Add undocumented auto-gifting(s) to the json #929

Merged

OpenUserJS locked as resolved and limited conversation to collaborators Apr 12, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

More modals needed for confirmation #261

More modals needed for confirmation #261

Martii commented Jul 13, 2014

sizzlemctwizzle commented Jul 13, 2014

Martii commented Jul 13, 2014

Martii commented Jul 13, 2014

Martii commented Jul 13, 2014

Martii commented Jul 13, 2014

sizzlemctwizzle commented Jul 13, 2014

Martii commented Jan 10, 2015

sizzlemctwizzle commented Jan 11, 2015

Martii commented Jan 11, 2015

Martii commented Jan 11, 2015

More modals needed for confirmation #261

More modals needed for confirmation #261

Comments

Martii commented Jul 13, 2014

Progress

sizzlemctwizzle commented Jul 13, 2014

Martii commented Jul 13, 2014

Martii commented Jul 13, 2014

Martii commented Jul 13, 2014

Martii commented Jul 13, 2014

sizzlemctwizzle commented Jul 13, 2014

Martii commented Jan 10, 2015

sizzlemctwizzle commented Jan 11, 2015

Martii commented Jan 11, 2015

Martii commented Jan 11, 2015