search

uclibs / scholar_uc_legacy

Source code for Scholar@UC up to version 3.x. Replaced by ucrate
Other
5 stars 1 forks source link

Discuss re-enabling the share tab for works #1243

Closed hortongn closed 7 years ago

hortongn commented 7 years ago

Before Sufia 7.3.0 final was released, a change was made that hides the work share tab by default and only shows it under the right conditions within the mediated workflow. See https://github.com/projecthydra/sufia/issues/3134

I think we always want the share tab to show in Scholar. We can either hard code it to show or make sure the workflow allows it. Hard coding is probably the better option for us since workflows aren't always loaded properly for us in our local environments or sandboxes.

To re-enable the tab we just change https://github.com/uclibs/scholar_uc/blob/develop/app/views/curation_concerns/base/_guts4form.html.erb#L8 from <% tabs ||= %w[metadata doi files relationships] # default tab order %> to <% tabs ||= %w[metadata doi files relationships share] # default tab order %>

Thoughts?

crowesn commented 7 years ago

Decision to hard code the share tab since we're already overriding the partial.

crowesn commented 7 years ago

@uclibs/developers Just tested with custom workflow and confirmed that share tab does not appear in create action; only accessible on edit. So we may want to override to hard-code the share tab.

hortongn commented 7 years ago

I guess we also need to test that sharing actually works on create if we force the share tab to show. Kyle said that when he manually went to the hidden #share tab and added an editor, it didn't save.

So if we want a user to be able to share at the time a work is created, we may have more work to do.

Guess we need to decide if sharing on work create (not just edit) is required functionality. Is it that bad if a user needs to first save a work and then edit again to add editors?