server Simple support to sync users from SG over to Ayon
#76
Conversation
Before, we had the opportunity to visually identify the underlying issues within those specific projects and proactively address them. Now, without this visibility, valuable time may be spent attempting to pinpoint the root cause of any unexpected occurrences |
Fair, in my case I prefer it this way as otherwise there's lots of noise of template projects and other legacy things that I know for sure I won't ever sync and a table widget is already clunky enough for this workflow that the more filtering the better. Also the documentation that shows in the same page clearly states both requirements for the sync to work... I think I´d rather steal the UI from another of the addons that might have spend more time trying to make this friendlier. Can you show a screenshot of the addon-ftrack and addon-kitsu to compare how they handle it? |
|
You you have a chance @fabiaserra please resolve conflicts and lets merge it ;) |
Done, please respond to https://github.com/ynput/ayon-shotgrid/pull/86/files/25d1b7fdf244e229a21bb404ddbe48bea0192f13#r1565979186 |
jakubjezek001
added
the
type: feature
|
@jakubjezek001 the ball is in your court - can we merge this? |
|
Also @fabiaserra would you mind to merge latest develop into your branch? Thank you. |
You did it no? |
Yeah I have done it - didn't know I can do it myself ;) |
frontend/dist/shotgrid-addon.js
Outdated
| const createNewUserInAyon = async (login, email, name) => { | ||
| call_result_paragraph = document.getElementById("call-result"); | ||
|
|
||
| response = await ayonAPI | ||
| .put("/api/users/" + login, { | ||
| "active": true, | ||
| "attrib": { | ||
| "fullName": name, | ||
| "email": email, | ||
| }, | ||
| "password": login, | ||
| }) | ||
| .then((result) => result) | ||
| .catch((error) => { | ||
| console.log("Unable to create user in AYON!") | ||
| console.log(error) | ||
| call_result_paragraph.innerHTML = `Unable to create user in AYON! ${error}` | ||
| }); | ||
| } |
There was a problem hiding this comment.
it seems this api call is obsolete or I am not sure why is the console erroring it
@martastain can you have a look into this?
There was a problem hiding this comment.
hmm yeah I'm not sure, my syncs still work fine, I just synced a few more differences I had on our fork
There was a problem hiding this comment.
So some changes needed to be done so we could merge this. Please review following PR on your fork @fabiaserra fabiaserra#1. This should probably interfere with your user base since we are only normalizing users which are having email in login. Also I had removed the password and active flag since it is active by default. The original SG login was added into user.data.sg_login.
|
FYI I recently just finished adding accessGroups synchronization in our fork of |
As I commented on this issue #130 (comment) I have expanded the sync users functionality so it's now driven by the Shotgrid events when there's a user assigned to a project, making the |
|
I am wondering if we need this PR or we should just move to syncing users via regular event system. Having separate javascript logic just for that seems weird. |
yeah as I said it still has a small use case for forcing the sync of users without the need for an event, in the case where users don't have a project assigned yet. It's very few cases where that could happen but it also helps for debugging purposes so it doesn't hurt to have it. On any case, I have both workflows implemented on my fork already |
- Added user ID to the new user creation function. - Enhanced login validation by sanitizing input and ensuring it meets specific patterns. - Updated API call to use validated login format.
|
This PR needs to be merged before we proceed into #113 . Some enhancements needed to be added so we could merge it. Validation of login string for example and storing SG user ID number in User entity data key as |
Quick implementation to sync the user database from SG to Ayon.
This also adds a change to the existing populate tables functionality to filter out all the projects that we wouldn't be able to sync (because they have whitespaces or not a code name) so the table isn't that long and it's easier to navigate through the projects... although ideally the whole server UI needs a revamp