-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLDR-16499 Prepare to Require a CLA for contributions #3653
Conversation
- new claSigned bit must be true to allow writing - store CLAs as JSON blobs in user prefs - API to read/update/revoke CLA - static list of signatory orgs - new menu item for CLA Other improvements/ - store JSON in the user settings data - load .md file via webpack - display markdown using marked (same as the error/wikimedia abstracts) - fix the client so that it doesn't hit the OpenAPI spec multiple times
Hooray! The files in the branch are the same across the force-push. 😃 ~ Your Friendly Jira-GitHub PR Checker Bot |
@btangmu I'll fix this so that the unit tests don't need to sign a CLA ! I'm just wondering if for local testing we want a switch that auto-signs the CLA? But then again, if you create a vetter in a signing org such as Apple Google Microsoft then it won't ask for a CLA. |
@btangmu i think this could get any feedback from you if you want to provide it, knowing we still need to review the text and the overall process. But let me know if you see any structural issues. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove the commented-out code change for MainMenu.vue?
I made a couple other nit-picky comments (which I don't insist on), otherwise, it all looks great
the menu item was removed because it's not relevant while CLAs are not required. I've changed it to being driven by a constant. |
@btangmu ready to review for merging and mothballing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, except I suggest renaming "signed" to "dateSigned", since it's a Date, not a boolean (unless I still misunderstand), and fixing the front-end comment saying it's boolean
I've left a few comments/questions I had while studying the PR, even though I was eventually able to answer them for myself. I think it would help to add some clarifying comments for maintainability. On the front end, "user.claSigned" really means the user has signed OR doesn't need to because DO_NOT_REQURE_CLA
@@ -39,6 +46,7 @@ public UserInfo(int userid) { | |||
this.org = null; | |||
this.emailHash = null; | |||
this.name = "User #" + userid; | |||
this.claSigned = false; // TODO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO should have ticket link; and it's not clear what needs to be done, if anything; false makes sense for a logged-out user
* @property {string} name | ||
* @property {boolean} unauthorized true if cla load failed | ||
* @property {boolean} readonly true if cla may not be modified | ||
* @property {boolean} signed true if signed, always true when returned from getCla() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
on the back end, it looks like "signed" is a Date rather than boolean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch, that should be the date signed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should that still be changed to a date, then?
public boolean corporate; // signed as corporate | ||
|
||
@Schema(required = false) | ||
public Date signed; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Date not boolean, but front-end comments say it's boolean
} else if (ClaSignature.DO_NOT_REQURE_CLA | ||
&& !config.getProperty("REQUIRE_CLA", false)) { | ||
// no CLA needed unless CLDR_NEED_CLA is true. | ||
return new ClaSignature("DO_NOT_REQURE_CLA"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this constructor presumably sets signed = true or signed = Date... OK, I've confirmed this suspicion
this.name = "Testing CLA: " + string; | ||
this.employer = "Testing CLA"; | ||
this.corporate = true; | ||
this.signed = new Date(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, here's the constructor used for DO_NOT_REQURE_CLA, setting signed = Date, which is treated as true
@@ -153,6 +161,10 @@ export default { | |||
this.voteCountMenu = null; | |||
this.voteLevelChanged = 0; | |||
} | |||
|
|||
// only need CLA if logged in | |||
this.needCla = !!user && !user.claSigned; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing that if DO_NOT_REQURE_CLA is true on the back end, then user.claSigned will get true (or truthy Date object?), even though that's sort of a fiction... OK, I've confirmed that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
@btangmu I'll fixup this one and get it in. It has a number of general improvements. |
@btangmu @macchiati this is ready to go in. it is disabled by default, but gets all the mechanism for requiring a CLA in place (just pending wording changes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sgtm. Tom should review details
@macchiati Tom had previously approved, just had merge conflicts. |
CLDR-16499
For v46, we do NOT require a CLA, but leave the code in place for the future
property
REQUIRE_CLA
off by default, if on it will enable the flowno popups or menu items visible to users
enables loading .md files to the front end and as assets
improve cldrClient.getClient() to cache, speedup repeated calls
add notice for synchronizing webpack configuration
APIs for sign/revoke/read CLA
web flow for signing CLA and handling various cases
This PR completes the ticket.
ALLOW_MANY_COMMITS=true