Seeing need for a few enhancements to the Contributions plugin.
- Ability to make certain fields (elements) required. I’d rather not have something submitted with no Title.
- Ability to re-order the form (element order). It may be cosmetic, but logically I want Title at the top, not the bottom.
- Ability to force publish to be checked or remove the option. I’m not sure why you’d ever want someone to contribute an item that can’t be used, seems pointless, and I’m not seeing how the admin can override this option and publish anyway, which is a problem.
- Ability to disable the “Keep Identity Private” aka “Anonymous” option. While I can understand some use cases for this one, in our case it’s just asking for problems.
Thanks!
For number 2 at least, you should already be able to drag and drop the elements to reorder them when editing a contribution type.
You’re right, for some reason this was not the case before, I’m guessing a browser page load glitch, or I was testing in a different browser where drag and drop wasn’t working.
But, I’ll add another issue to take its place. Contributors can see the Contributed Items navigation item when they log in. They should not, as they have no rights to do anything in there. It looks like they can, but when clicking things (like make public) they just spin and do nothing, but really they shouldn’t see the tab at all.
The idea of the contributor role is, generally, to be a little above the role of the researcher – someone who can look around at non-public content and add their own, but not to make changes. That’s so people can study content in an academic setting, while leaving some or all of the content unpublished, a significant need for classes.
Well, much bigger issue, there is a fatal bug in this plugin, items can’t be made public. If you use either the link in the item row on the Contributions tab, or click its box and click the Set public button, it says it made it public but does not. Reloading the page shows nothing changed. If you edit the item and check Public and save Changes it spits back a page that is clearly a thread of information that should be going into an email ending with "MIME-Version: 1.0
Content-type: text/html; charset=iso-8859-1"
I will note that before I fixed the broken sendmail on the server this was not an issue. Now that sendmail is working (all steps of the Guest user process for example) this is busted. Seems there is a mail function in the plugin for alerting the contributing person that their item is public that is quite broken.
I haven’t been able to reproduce this. Could you give the versions of Omeka and Contribution you are using, and more details about submission options you have set when contributing an item?
Omeka 2.4.1 and Contribution 3.1.0
Settings are:
Slug: blank
Confirm and notification emails: set
ToS: filled in
non registered and anonymous options: off (unchecked)
email to contributors: filled in
collection: chosen
default type: Image
Hmmm…still no dice on my end reproducing this. Could you post up the content of that page that gets spit back. Maybe more about the error message will help debug this.
yadinf@psu.eduYour contributed item has been publishedThank you for contributing to the PSU VRC Omeka system. Your contributed item has been approved and can now be viewed at the following link: ViewMIME-Version: 1.0 Content-type: text/html; charset=iso-8859-1
The URL displayed is the item url, that doesn’t change, and trying to view the page source to get anything further indicates you must reload the form submission.
Every time I make it public (by any means) an email is sent to the user confirming it has been made public, but it’s not been made public. Admin can see it, the user can see it, but public can not. Additionally, the email is sent from www-data instead of the email specified in the Contribution plugin Settings, so that’s also a bug that needs to be addressed. That only happens on the make public step, all other stages of contribution emails to the user and admin work properly and come from the correct source. I have tried adding a new item under a new account, same behavior. Tried both Chrome and Firefox, cross platform, same behavior.
This sounds basically identical to an old forum thread which traced the issue to the UC Santa Cruz “Contributor Contact” plugin.
The Contribution plugin itself doesn’t send any messages with the text you’re showing here, so I assume it must come from that plugin instead. This line in particular is quite likely relevant.
Though Patrick suggested it at the time, it doesn’t look like the issue from back then was ever reported to the plugin’s issue tracker.
We have a winner! I forgot that plugin did the alert of publication and not the Contribution plugin. So it seems that contact plugin is just flat broken as the email is not sent correctly (coming from www-data) AND it causes publication to fail outright. I don’t know nearly enough about the code to fix it, but I’m happy to test any suggested code changes anyone might have. We’d really like that notice to work so people know when an item went live.
Thanks!