/    Sign up×
Community /Pin to ProfileBookmark

Need help coming up with an approval process

Copy linkTweet thisAlerts:
Mar 07.2016

So I’m a co-op student who’s working with Mura for the first time ever. It’s been fairly easy to figure out, but I wonder if maybe my current task is beyond my expertise.

My boss has forms on the website, and a MySQL database. What he wants is for form info to go through an approval process before being automatically added to the database. Since Mura emails form data, the info would get passed around from person to person within the approval chain via email. Then the person at the top of the chain hits a magical “approved” button, and the form info would then go straight to the database.

I have no idea how to actually get something like this working. According to the Mura site, form info is stored in an .xml file somewhere, but neither my boss nor I think we’ll be able to get access to the bare bones part of Mura where that file is stored.

Anyone have any ideas on how I could implement such an approval process? I asked on the Mura forums but have received no help. ?

to post a comment
Full-stack Developer

5 Comments(s) ↴

Copy linkTweet thisAlerts:
@cbVisionMar 07.2016 — I'd just create an additional table in your MySQL database to store this pre-approved stuff. Once approved, you'd simply move the item into the main table.
Copy linkTweet thisAlerts:
@NogDogMar 07.2016 — I'd leave it all in the same table, but either add an approval column to the applicable table, or create a separate approval relation table. In either case, you'd only display the info to "normal" users if the approval column is set to whatever status value you choose, otherwise it would only be accessible by the "approvers". However, knowing zero about this Mura thing, I have no idea how it interacts with and uses the data in question, so I don't really know what the specifics would be to implement that.
Copy linkTweet thisAlerts:
@cbVisionMar 07.2016 — I'd leave it all in the same table, but either add an approval column to the applicable table, or create a separate approval relation table. In either case, you'd only display the info to "normal" users if the approval column is set to whatever status value you choose, otherwise it would only be accessible by the "approvers". However, knowing zero about this Mura thing, I have no idea how it interacts with and uses the data in question, so I don't really know what the specifics would be to implement that.[/QUOTE]

Agreed, I had originally typed up the same concept, but changed my mind thinking that they had a reason they didn't want "clutter" in the table. Maybe preventing spam to get in there? I dunno. Obviously there are ways to clean that garbage out too. Anyway, yes, that's how I'd handle it too.
Copy linkTweet thisAlerts:
@NogDogMar 07.2016 — There's almost always more than one non-wrong way to do these things. ? I'm admittedly prejudiced by the fact that the service I work on at work for reviews of medical providers has one review table with a separate moderation_log table to track status changes that control review visibility. ?
Copy linkTweet thisAlerts:
@catdauthorMar 08.2016 — I'd leave it all in the same table, but either add an approval column to the applicable table, or create a separate approval relation table. In either case, you'd only display the info to "normal" users if the approval column is set to whatever status value you choose, otherwise it would only be accessible by the "approvers". However, knowing zero about this Mura thing, I have no idea how it interacts with and uses the data in question, so I don't really know what the specifics would be to implement that.[/QUOTE]

This is actually a pretty good idea! My boss wanted something very easy, that wouldn't involve having to go into the table to do anything, but this is probably the most reasonable way to get it done. Thanks!
×

Success!

Help @catd spread the word by sharing this article on Twitter...

Tweet This
Sign in
Forgot password?
Sign in with TwitchSign in with GithubCreate Account
about: ({
version: 0.1.9 — BETA 5.18,
whats_new: community page,
up_next: more Davinci•003 tasks,
coming_soon: events calendar,
social: @webDeveloperHQ
});

legal: ({
terms: of use,
privacy: policy
});
changelog: (
version: 0.1.9,
notes: added community page

version: 0.1.8,
notes: added Davinci•003

version: 0.1.7,
notes: upvote answers to bounties

version: 0.1.6,
notes: article editor refresh
)...
recent_tips: (
tipper: @AriseFacilitySolutions09,
tipped: article
amount: 1000 SATS,

tipper: @Yussuf4331,
tipped: article
amount: 1000 SATS,

tipper: @darkwebsites540,
tipped: article
amount: 10 SATS,
)...