Add additional scenarios to gherkin for sync resources workflow#2983
Conversation
|
Thank you, Marcella, for initiating the conversation and describing the feature, this has been very helpful. |
|
Thank you @marcellamaki 👍🏽 Before we continue, I suggest checking the Style guide for I'll have to run a few tests to remind myself what exactly is the desired behavior for the second option 🤔 |
|
@marcellamaki Here's what I've found so far as a current behavior of the Sync functionality (tested at the hotfixes branch): CASE 1 CASE 2 |
|
Hi @marcellamaki and @radinamatic Issues observed so far:
Suggestions for improvements:
Question: |
|
More notes from today's testing effort: Issues:
Observations and considerations:
|
|
@pcenov Thank you for the in-depth investigation! 💯 Please report the following as syncing issue (do a search to confirm there is not one already):
As for thumbnails, re-check if it takes more than one re-fresh to see them updated, it's what I seemed to have experienced. Report your suggestions for improvement as a separate issues for string update (1), and feature request (2). The latter will need design decisions, and may not be viable or recommended in case the list of changes is too long...? 🤔
cc @jtamiace @khangmach @rtibbles Is that the intended user experience?
Could that be some delay database update, or the resources are being synced
Channel structure (topics & subtopics) do not get synced, just single resources and their details, so as far as I understand syncing will not register changes like additional files in originally imported topic, just changes (if any) in individual files in that topic. |
|
Hi @radinamatic I've reported the following syncing issues: #3111 - Sync resources - Some fields in 'Edit details' don't get updated after attempted sync #3112 - Sync resources - The option to sync 'assessment details' is not functioning #3113 - Sync resources - Existing file thumbnails won't get synced and updated And this as a feature request: I noticed that there's an existing issue for stopping the sync here: #1740 And also there's an issue for modal improvements here: #2971 |
Yes, this is intended. Whether it's desirable, I am less sure - but I think that's the summary of the sync experience! |
|
Ok, let's leave it at that for now, as I'm not aware that any user had expressed the need to have a different workflow. If/when it happens, we'll revisit! 👍🏽 |
Added more granular steps
|
Thank you @radinamatic and @pcenov for all of your work and investigation on this!! ✨ |
Codecov Report
@@ Coverage Diff @@
## hotfixes #2983 +/- ##
============================================
+ Coverage 80.80% 86.12% +5.31%
============================================
Files 281 305 +24
Lines 12659 16459 +3800
============================================
+ Hits 10229 14175 +3946
+ Misses 2430 2284 -146
Continue to review full report at Codecov.
|



This PR is to add more scenarios for the gherkin re: "Sync Resources"
I will explain my findings here (in non-gherkin!), and I would appreciate any comments, discussion, or suggestions for how to improve the gherkins, because I want to be sure they're quite clear and the workflow is not necessarily the most intuitive.
In Studio, if a user imports some content from a channel, there are two different ways this content might "sync":
The first option is if the user has imported some content, made no changes to it, but the original/source content/channel has been updated. If the user syncs resources, then they will be fetching any updates from that new change (as long as they check off the things they want to update - tags, titles, etc.)
The second option is if the user has imported some content, and they have made changes to it. In this case, when the user syncs the resources, their edits are overwritten by the current state of the source content. (This could be v1 of the original content, or it could be a situation like the scenario mentioned above. If there are changes in both, then like the above the "source/origin" version is prioritized, even if it's been updated).
This, as far as I can tell, is the "expected" behavior.
On a separate/parallel track and for a later date:
It might be worth thinking about
There is some technical debt around this in general as @MisRob has helpfully illustrated in 2969 and I think having a better sense of if people are using it and how people are using it would be helpful before undertaking that refactoring.