dfeeney
commented
10 years ago Hi @wamberg,
On Dec 12, 2013, at 3:25 PM, Bill Amberg notifications@github.com wrote:
I've been looking at our support pipeline. Specifically I've been trying to POST augmentation issue data to viewshare.apps.support.views.AugmentationIssueView.
One issue I'm having is that we deleted freemix.dataset.models.parse_profile_json in the master branch from the development branch. Should this function should be revived and updated for our new DataSet-less development branch?
No, I think we used that function previously because the augmentation process was happening completely in-browser. Now, with the draft model, all of the information is stored on the server, so now we’d need to copy that similar to copying a published exhibit to draft.
The second issue is with our support process. If the pipeline were working parse_profile_json would create a duplicate DataSet (I imagine this will be a DraftExhibit in the develop branch) owned by a settings.SUPPORT_USER. This DataSet is always publicly viewable. This is a great idea for support purposes because we can see the data in Viewshare in the state that caused the augmentation error. The unwanted side-effect is that a potentially unpublished DataSet will be marked as published for the SUPPORT_USER. Should we be creating duplicate public DataSets (DraftExhibits) for support? The options I see are:
Don't create duplicate data. Force support staff to manually follow up with user that had the augmentation issue. (I don't like this option.) Don't create duplicate data. Include a link to the user's DraftExhibit that had the augmentation issue. We'll be able to see the data but we'll have no guarantee that it's in the same state that caused the issue. Create a duplicate DraftExhibit for the SUPPORT_USER. I believe you'll only be able to access the DraftExhibit if you're logged in as SUPPORT_USER. I think the last option is the best. Did I misread the support pipeline? If so, any direction is appreciated. If I'm on the right track, what do you think about our options? Thanks!
Yeah, I think that’s a good summary and the last option is probably the best. Anyone who has the staff flag for admin and the appropriate permissions should be able to see the linked DraftExhibit. One thing to be aware of is that the unique constraint on slug might be an issue with similarly named exhibits from different users. You’ll probably want to just make it a UUID or something. The whole SUPPORT_USER thing is a big kludge.
Another option is rather than making a copy of the exhibit, copy the data source and detail the augmented fields in the issue email. This would basically give the support personnel a script to work off of without duplicating the actual exhibit.
As a massive digression (to get it down on paper), one appealing, but impractical, idea is actually subclassing Exhibit into SupportExhibit, basically something that doesn’t require user/slug. Unfortunately, the data model won’t allow that, as user/slug need to be unique constraints for published and draft exhibits. If I had it to do over again, I’d make the Exhibit base model abstract and create factories for models (properties, etc) and views that link to it, so a separate table structure would be created for each exhibit type. I’ve experimented with that model in the past and it ends up with a lot of boilerplate, but that might be better than the current situation.
wamberg
Hi @dfeeney,
I've been looking at our support pipeline. Specifically I've been trying to POST augmentation issue data to viewshare.apps.support.views.AugmentationIssueView.
One issue I'm having is that we deleted freemix.dataset.models.parse_profile_json in the master branch from the development branch. Should this function should be revived and updated for our new DataSet-less development branch?
The second issue is with our support process. If the pipeline were working parse_profile_json would create a duplicate DataSet (I imagine this will be a DraftExhibit in the develop branch) owned by a settings.SUPPORT_USER. This DataSet is always publicly viewable. This is a great idea for support purposes because we can see the data in Viewshare in the state that caused the augmentation error. The unwanted side-effect is that a potentially unpublished DataSet will be marked as published for the SUPPORT_USER. Should we be creating duplicate public DataSets (DraftExhibits) for support? The options I see are:
I think the last option is the best. Did I misread the support pipeline? If so, any direction is appreciated. If I'm on the right track, what do you think about our options? Thanks!