Skip to content

Validate @oujs:author to match current username #208

Closed

Description

@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.

Activity

  1. cletusc commented on Jun 26, 2014

    @cletusc
    Contributor

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

    // @author Ryan Chatham <ryan.b.chatham@gmail.com> (https://github.com/cletusc)
    
  2. Martii commented on Jun 26, 2014

    @Martii
    MemberAuthor

    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:

    So I can possibly recommend:

    // @copyright 2014+, Ryan Chatham (https://github.com/cletusc)
    // @supportURL mailto:ryan.b.chatham@gmail.com

    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)?

  3. sizzlemctwizzle commented on Jun 27, 2014

    @sizzlemctwizzle
    Member

    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).

  4. Martii commented on Jun 27, 2014

    @Martii
    MemberAuthor

    Yeah it is

    ahh kewl... good to know. :)

  5. cletusc commented on Jun 27, 2014

    @cletusc
    Contributor

    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 <b@rubble.com> (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. ;)

  6. Zren commented on Jun 27, 2014

    @Zren
    Contributor

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

  7. cletusc commented on Jun 27, 2014

    @cletusc
    Contributor

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

    This is an even better option, IMO.

  8. Martii commented on Jun 27, 2014

    @Martii
    MemberAuthor

    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.

  9. Zren commented on Jun 27, 2014

    @Zren
    Contributor

    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?

  10. Martii commented on Jun 27, 2014

    @Martii
    MemberAuthor

    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:

  11. sizzlemctwizzle commented on Jun 27, 2014

    @sizzlemctwizzle
    Member

    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.

  12. Martii commented on Jun 27, 2014

    @Martii
    MemberAuthor

    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.

  13. sizzlemctwizzle commented on Jun 27, 2014

    @sizzlemctwizzle
    Member

    I prefer the former as well.

  14. 21 remaining items

  15. Martii commented on Aug 3, 2015

    @Martii
    MemberAuthor

    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
  16. self-assigned this
    on Aug 3, 2015
  17. added
    bugYou've guessed it... this means a bug is reported.
    needs testingAnyone can add this but it is primarily there for the Assignee indicating that Testers are wanted.
    and removed
    enhancementSomething we do have implemented already but needs improvement upon to the best of knowledge.
    laterA long time ahead, in a galaxy near, near...
    questionA question has been encountered by anyone and has remained unanswered until cleared.
    on Aug 3, 2015
  18. Martii commented on Aug 3, 2015

    @Martii
    MemberAuthor

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


    May be related to #686 ??

  19. removed their assignment
    on Aug 4, 2015
  20. locked as resolved and limited conversation to collaborators on Apr 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CODESome other Code related issue and it should clearly describe what it is affecting in a comment.UIPertains inclusively to the User Interface.bugYou've guessed it... this means a bug is reported.needs testingAnyone can add this but it is primarily there for the Assignee indicating that Testers are wanted.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions