Validate @oujs:author to match current username

[Martii]

Currently any username can be put in and allows any @collaborators to show up.

EDIT: Also shows "Submit Code" on Source Code page... although it does 404 when tried to commit. I think this is a good thing although should fail more gracefully.

EDIT: Changed keyname in the subject to our current supported instead of @author.

EDIT: Maybe find script in @oujs:author's list... if not present disable and/or prevent uploading.

[cletusc]

How, if at all, would this affect my script?

// @author Ryan Chatham <[email protected]> (https://github.com/cletusc)

[Martii]

How, if at all, would this affect my script?

Great question. Basically from my understanding of this is if @author isn't in OUJS format the @collaborators should be ignored and any kind of collaboration will not be available... I don't think this feature is working yet but the first step is to make sure they show for testing. I'm open to suggestions as far as how to handle this within last value used sort of guidelines... currently it is set to unique... so last value is always used in OUJS context.

EDIT: Ideally @copyright would be a more suitable place for your name and website though... @supportURL and @homepageURL supports mailto protocol for your email address. From an educated guess @author was originally designed to work-around USOs lack of a vanity name... e.g. use this key instead of a numeric id.

See tracked:

• Updated AddonManager userscripts to match other addon-types greasemonkey/greasemonkey#1861

So I can possibly recommend:

// @copyright 2014+, Ryan Chatham (https://github.com/cletusc)
// @supportURL mailto:[email protected]

EDIT: Does any user.js engine have @author officially defined and not conflicting/redundant with @copyright (this key is formatted from copyright.gov. Usually copyright is expressed as © Copyright 2014 Marti Martz, All/Some Rights Reserved but licensing leverages the All/Some Rights Reserved so it is omitted especially in OSI ... the paren'd website is part of your "name" identification)?

[sizzlemctwizzle]

I don't think this feature is working yet

Yeah it is. I updated one of your test scripts a few days ago (you had me listed as a contributor).

[Martii]

Yeah it is

ahh kewl... good to know. :)

[cletusc]

FWIW, I am using the meanings of many keys as the same as how npm handles people in package.json files:

people fields: author, contributors
The "author" is one person. "contributors" is an array of people. A "person" is an object with a "name" field and optionally "url" and "email", like this:
...
Or you can shorten that all into a single string, and npm will parse it for you:
Barney Rubble <[email protected]> (http://barnyrubble.tumblr.com/)

There is also a cheat sheet from nodejitsu. I consider the JSON-to-userscript-metadata as any string becomes // @key value and any array becomes multiples of that same format.

My support url should be as I've defined it--I don't want people sending all of their issues to my email, but I still want my email out there.

Edit: Perhaps this might be a key we should keep namespaced to OUJS. If greasyfork implements the same feature, and my username is different from mine here, there will be conflicts. I would prefer @oujs:author cletusc and @oujs:collaborator Martii over trying to redefine what author means.

Edit: maybe we could set a standard for all engines/wikis out there? package.json seems to be a pretty good starting point. ;)

[Zren]

Tbh, collaborators should probably be managed similar to groups, rather than reading it off the script itself.

[cletusc]

Tbh, collaborators should probably be managed similar to groups, rather than reading it off the script itself.

This is an even better option, IMO.

[Martii]

Tbh, collaborators should probably be managed similar to groups, rather than reading it off the script itself.

Not possibly cross site compatible though... but @author has some issues.. which is why it should be validated... and validation can be applied to @contributor too.

[Zren]

Not possibly cross site compatible though.

Which is sort of the point. You're already getting into prefixing the tags because a user might not have the same username on all sites implementing it this way. Which sites support this anyways?

[Martii]

You're already getting into prefixing the tags because a user might not have the same username on all sites implementing it this way.

Which is why I mentioned a little while back we should probably support prefixing with metadata keys e.g. as a rough comparison uso:script, and oujs:script, etc... this wasn't included in the original CI routine import... and I wasn't here yet to throw in my two cents. The prefix is the equivalent of a namespace for anyone using it upstream or cross-stream

As far as:

am using the meanings of many keys as the same as how npm handles people in package.json files

key prefixing could help this e.g. npm:author ... as a root key user.js is not a npm package... this is like trying to get XMP and EXIF in images to use the exact same data structure naming sequence... not going to happen. Root keys should be minimal in general but again I didn't create the new ones here on OUJS and Scriptish defined way too many root keys... he should have prefixed those or not created them imo.

See tracked:

• Feature: Add "more" link on scripts in addon manager greasemonkey/greasemonkey#1944

[sizzlemctwizzle]

collaborators should probably be managed similar to groups, rather than reading it off the script itself.

This is originally what I planned, but then I realized that you use these keys to give people credit already. Why not use them for managing collaborative permissions while you're at it? This way users who have permissions to edit a script are automatically credited/documented in the script.

Anyway, I'm totally fine with using a prefix if we want to go that way.

[Martii]

I'm totally fine with using a prefix if we want to go that way.

Did anyone want it separated out like I do in installWith and Count Issues e.g. meta.uso.script (or meta["uso"]["script"] like I usually do just in case there is a weird character that can't do dot object notation) or just meta["uso:script"] e.g. we'll lose dot object notation in our source? I recommend the former personally from experience.

---

I realized that you use these keys to give people credit already.

That's was a great idea and I'd give it a +1 in retrospect... everyone likes attribution. :) Just needs a prefix ... so I'm +1 for that.

[sizzlemctwizzle]

I prefer the former as well.

[cletusc]

I'll prefer the former and have it prefixed under oujs. Author should mean the same thing, regardless of implementation. For site-specific "extras" (like collaboration), we should prefix it or go with the "groups"-like option.

[Martii]

I'll prefer the former and have it prefixed under oujs.

Thanks.

Which sites support this anyways?

None yet that I know of but #96 and #77 could be used in concert with these issues rather than have a bazillion settings to manage on all the sites... just have @JasonBarnabe declare what he wants for a prefix and we'll use it... within JavaScript identifier naming guidelines of course to maintain dot object notation. e.g. no dashes or pluses etc. GM and google already broke this naming rule with run-at which I couldn't prevent with my other 2 cents at the time.

---

The remainder of @OpenUserJs/admin should vote on prefixing vs groups too. Sizzle does have the final word because he's footing the hosting bills but we need not be divided on this since it's a fairly doable thing either way. This is the second issue I've had to mention prefixing so it's starting to become a necessity I think.

[JasonBarnabe]

I don't have any Greasy-Fork-specific keys and don't plan on adding any, but if you need to know what I'd prefix them with if I ever use them, it would be gf.

[Martii]

for example automatically pulling in changes when you commit to GitHub (or wherever!)

#208 (comment)

don't plan on adding any, but if you need to know what I'd prefix them with if I ever use them, it would be gf.

greasyfork-org/greasyfork#145 (comment)

@supportURL it is then.

Thanks JasonBarnabe from GF

---

greasyfork-org/greasyfork#145 (comment)

+1 @supportURL

Thanks arantius from GM

---

greasyfork-org/greasyfork#145 (comment)

I think @supportURL can enhance this to either report general issues (i.e. malware) to the script source page or more specific problems directly to the author.

Thanks derjanb from TM

[Martii]

@jerone Cc: @arantius
Sidetrack but related: I just wanted to say that greasemonkey/greasemonkey#1861 is nice... finally got around to running some tests on it. It does have at least one bug in it... It doesn't follow GMs default rule of picking the last value if multiple keys are found for single referenced entities. e.g. your @homepageURL picks the first one it encounters and probably any other key you are trying to get supported... not to mention we at OUJS currently support all of them with the last being primary and displaying in reverse the remainder. If you could simplify the feature set in a pull request not to include so much, upstream might be willing to take it under consideration a little further. Also when you delete your repo branch it makes it a nightmare to pull into cross-stream projects e.g. you might lose automatic attribution... I can of course pull each commit, compare it to near current standards, and then cross examine in GMP... and it appears that you are behind the current GM master with it which adds to even more complication... it'll bitrot if some of these things don't get addressed and become vaporware.

---

I do agree with Anthony saying the context menu should not be submenu'd... I have a bazillion add-ons and user.js at times and things get really slow even on newer computers... this includes DnD being super slow and more difficult to maintain especially since there is execution order sorting.

See also:

• Remove duplicate meta data item values e.g. homepage and homepageURL #232

[Martii]

@sizzlemctwizzle @arantius

Personally, in all my years of using GM I've never once changed the execution order of a script, so I really have nothing to say except that'd love to have it out of the way.

I have... when another script creates a DOM element that I am expecting to be there to reference off of... setTimeout isn't always reliable for waiting, and for how long... that is one of the fixes that I had to do to your UCF that you didn't seem to understand at the time with textarea... and until just recently setTimeout had some security issues but I think execution order is still necessary... also in the OUJS STYLEGUIDE it claims that it uses eval ... so setTimeout isn't as good of a methodology I think. MutationEvents is just overkill sometimes.

---

sizzlemctwizzle wrote:

Marti wrote:

• before you were handling it as a reply only, even if it was an edit, and prevents other related scripts from working with UCF. (spent a solid four hours testing this btw)

Seems to still work in my minimal testing, so we're good.

---

I'm still +1, for what it's worth, on the greasemonkey/greasemonkey#1861 but with the standardization Anthony instructed me about using last values as primary... was in reference to @icon I think... I'll see if I can find the link... here we go:

• Multiple @icon picks last value greasemonkey/greasemonkey#1233
• Multiple @icon picks last value greasemonkey/greasemonkey#1233 (comment) Important comment about USO which is what I've fixed on OUJS with Fix pseudo unique *(e.g. non-upmixed but unique)* @icon key to use **last value** only #188 in the last few weeks or so and maintained on all keys.
• https://github.com/greasemonkey/greasemonkey/wiki/Test-Cases#Duplicate_values

[cletusc]

setTimeout isn't always reliable for waiting, and for how long

I use an "exponential" setTimeout here and it is pretty effective. Basically try to work quickly at first but back off doubling each run through that the condition isn't met. I have no clue when, in terms of execution order, my script runs as it can be injected into the page by different addons. Honestly, execution order should be solved by an author, not a user, but the option exists to help users.

also in the OUJS STYLEGUIDE it claims that it uses eval ... so setTimeout isn't as good of a methodology

Passing a string into setTimeout uses eval, e.g. setTimeout('alert("something");', 1000);; however, passing a reference to a method does not use eval, e.g. setTimeout(myMethod, 1000);. Timeouts are needed sometimes, so we should encourage the correct use of it.

[Martii]

Passing a string into setTimeout uses eval,

Good point... should our STYLEGUIDE.md #19 reflect this rather than being vague? We can still restrict any usage of it. I personally try to avoid it at all costs.

Honestly, execution order should be solved by an author, not a user, but the option exists to help users.

Problem is that will generate more noise to signal with issues... even with UCF and Spam Zapper I didn't find that issue without reordering... asking a user/author to manually check their config.xml and change the order doesn't seem like a good idea. Unfortunately the state of the art system for OUJS dev testing (less than a few months old) still is sluggish in the AOM... probably a Fx issue since it's not present in SM... and submenuing makes it slower with user experience.

it is pretty effective

Hopefully it's running in the right context from the Sandbox too... last check I did a few months back it wasn't... it was detached in a special zone under unsafeWindow.

[sizzlemctwizzle]

We can still restrict any usage of it.

I'd argue there is no good reason to use it in Node.js. If you're trying to force some function to run asynchronously use setImmediate (or process.nextTick if you really know what you're doing). If you're waiting around for something to occur with setTimeout, you really need to re-evaluate your code. In fact, I would probably automatically refuse any PR using setTimeout (or setInterval) if there wasn't a clear argument why it must be used, and even if then, I would be very skeptical.

As for client-side...

[cletusc]

As for client-side...

...of course, client-side only. We should know (relatively) where everything is running in node and/or use the methods you linked. 😄

[Martii]

If you're waiting around for something to occur with setTimeout,

In UCF's case it was initially waiting for something to not occur... until I fixed your source with the textarea then all I had to do was wait for your ES5 implementation to finish since my ES6 finished way before your script had a chance to finish... e.g. I overwrote/intercepted your ability to detect certain things to the comment area and broke your script if I didn't wait... and dependent on script execution order to figure this out. USO did do a few things right over the years but UCF was blocking any kind of script compatibility collaboration on that portion of the DOM for years.

I'd argue there is no good reason to use it in Node.js ... to force some function to run asynchronously use setImmediate (or process.nextTick if you really know what you're doing)

Noted... I'll emphasize it next round of doc updates if it doesn't get in there before.

Thanks guys. :)

[Martii]

Hmmm... this appears at first glance to have fixed itself with the recent mods... will recheck (all publishing methods) and close if there is no way of reproducing.

---

• New Write script online in my account... use sizzle as author and me as contributor... returns to the script editor. PASS
• New Upload script in my account... use sizzle as author and me as contributor... returns to file upload ... existing with reupload...returns to file upload screen... sync... doesn't sync which is expected PASS
• New GH import... 400 error while importing script ... existing on OUJS with reimport... 400 error PASS
• Edit script online... use sizzle as author and me as contributor... returns to source code edit. PASS

[Martii]

Seems to pass all the tests above... closing with needs testing (e.g. retesting) ... esp. in #285

---

May be related to #686 ??