Messages

  Entire forum

Auto Light Dark

English

Your looking for the shd_handle_attachments() function in that file.  SimpleDesk ties into SMF's attachment system (createAttachment in Subs-Post.php from SMF) and then uses its own table to maintain the relationship between the attachments table, its location and the ticket.  It doesn't use it own storage folders, but rather what was setup for SMF for its attachment location(s).

Something like this would work, but would have to be setup to run for your user id and database prefix.  You would run this on your database.

Code Select Expand


INSERT INTO {db_prefix}helpdesk_log_read (id_ticket, id_member, id_msg)
SELECT id_ticket, {YOURMEMBERID} AS id_member, id_last_msg AS id_msg
FROM {db_prefix}helpdesk_tickets


Lots of things going on in my life.  To the point where I don't even have enough to handle all my stuff and still have fun.  To be young again (and I mean a teen)

Sorry for my late reply.  I have almost no time nowadays for development.  Wish I could help more.  This project really needs some active developers.

Maybe in a future release, but this project lacks active developers at the moment to make that happen.  Not sure when a new feature release would appear.

Well it would be possible to do, SimpleDesk-Post.php source file would be what you need to modify and have it check in the new ticket if statement and then query up how many tickets they have created in an hour and see if that exceeds your limit.

Kinda defeats the purpose of the helpdesk and if people are submitting that many tickets, seems like something is going wrong with how they are using it

Your database is missing from the upgrade.  I wouldn't know/trust how Apple handles their upgrades, so I would assume that upgrading to Mavericks updated MySQL and removed all instances of the old database files.  That table set is basically the defaults.  This isn't so to speak a SMF/SD issue, but a OS issue from the upgrade resulting in a database loss.

The only thing I could think of would be to recover from backups, export your database as a backup, redo the upgrade and reimport the backup if they are lost again.

http://wiki.simplemachines.org/smf/Patching

Shouldn't be any issue applying the update.  I just did here with zero troubles.  In under 2 minutes even.

The problem with it is that you end up having to reduplicate a ton of stuff. For example you'd pretty much need to handle attachments yourself with all the joys of things like file permissions. By bootstrapping it with the existing attachments system (for example) there's no duplication and much lower support overhead.

It's quite possible we could still get it done with little overhead.  FYI, I am sure you know/remember, but the customize site uses SMF's attachment system as well.  It does do a lot of direct handling, more than I would want SimpleDesk to do, but still has SMF handle a good chunk of it.

If only that's what it actually did. The plugin manager still relies on the packages system to actually perform installs etc. and the language editor is a direct integration of the SD files.

We should be able to use PacMan and LE without being in SMF or get stuck in weird SMF issues like redirects and whatnot.  Yes there would be some code copying, but otherwise it may be doable.

assuming the rewrite doesn't generate new bugs.

That's a undocumented feature.

No chance it's going to work on Wedge. I did make the port to Wedge and mostly it worked last time I tested it, even allowing for all the bazillions of changes in our markup. But I realised ultimately that I want to rewrite from scratch for Wedge to fix some of the architectural issues that are present (e.g. being able to assign multiple people to a ticket and the mess that is the current 'items to do' count for each user), plus there's things like the Wedge notifications system that can be used now.

Doesn't mean that the abstraction layer couldn't call a notification system and in SMF it does emails or PMs and in Wedge it would do the notification system.  The API would basically say, here is this data, you handle it now.  For a notification system, we don't care about the results.  Other things we would and that would get tricky.

tfs,
Is there any such bugs which need addressed?  Trying to get back into SMF stuff, I should try to spend time with SD and get working with it again.

I'd be willing to install any number of test forums for you and I to work with.  I'll perform beta testing for you to your heart's delight. 

I use SimpleDesk daily in my real-world job.  I've probably worked through a thousand tickets since we started using it.  But as far as bugs go, I just don't have a good idea of what they are right now (besides the two Arantor linked).  Once the code went to GitHub I threw up my hands in frustration. 

I apologize that Git seems a bit confusing.  Moving to Github was a choice that was supposed to help bring exposure to our project and allow contributions.  Alas that hasn't really happened (although we did get help with SMF 2.1 compatibility).  Perhaps I can work on a way to bring more exposure to you guys when Git is updated.  Would a topic that gets a new reply every time we get a commit help out?  I think Wedge does that (or they do a lot of manual posting ).  It would help bring that to light, and I should be able to include a download link as well.

You and me both as far as Github is concerned... I know that there is some stuff in there for SMF 2.1 compatibility but I have no idea what the state of it is any more

2.1 Compatibility and that has been all really.  We need devs to work on it, but thats a challenge.  Big mods can be a challenge to work with.  Especially in a developer environment.  For me personally, I have SMF setup to where I can work between PHP 5.3 or PHP 5.5 and change my git branch around to whatever I want.  I did think about getting my databases going again, but haven't.  On my laptop I used to run 2 web servers (Apache and nginx), 3 versions of PHP (5.1, 5.2 and trunk (or 5.3 at that time), 3 database (MySQL, Postgresql and SQlite), and had a magic script that got appended that added easy upgrade handling, killing of sessions, changing themes, and switching between all the different softwares.
When I tried working with SimpleDesk, it wasn't as easy because of mostly my lack of SimpleDesk knowledge and that SimpleDesk required me to test mod installs every time I made a change to the package installer (I figured I could get away with modifying the none package edits/installer script).

Oh, I just realised something else; if SD were pushed into an SSI only context, might as well remove the plugin manager and edits to the language editor since neither will work properly in that situation, especially the plugin manager.

It was just a thought.  I toy with many ideas in my head.  Some of them are great, others are not.  I was toying with it to think how it would go.  My thoughts on it mostly would be that it would make it much easier to work with since we got a almost standalone install.  I think plugin manager would still be doable.  Its not like plugin manager can't still scan the packages directory or do the LE.  Its not like those couldn't link to the SMF stuff.  My thoughts where you would be able to decompress it into a directory, run the installer which would setup a settings file with the link to SMF SSI.php, and a few other basic settings and off you go.

I've also toyed with the idea of seeing what we could do to start a abstraction layer, so SMF isn't the only source it will work on but other forks such as Wedge could use SimpleDesk.  Mostly so we are not limiting people to using SMF only if they want a helpdesk.  It would make sure that SimpleDesk can communicate with other forks as long as the API is there.  Again, idea in my head, but not anywhere near paper yet.

venguard223,

Understandable, I just see no reason it can't rely on SSI and still pull the theme system and others.  The major thing I want to break out is the integration into SMF's main code (ie for topics and menu stuff).  I suspect with improvements in 2.1 having better hooks, we can do this.  Making it less of a mod and more of a Add-on that relies on SMF's SSI to do its stuff seems to be the best option for future.  It makes it work easier, easier to develop and makes it so a simple mod that adds the hooks is all that is needed to bring in the integration for menus, unread replies and topics.

tfs,
Is there any such bugs which need addressed?  Trying to get back into SMF stuff, I should try to spend time with SD and get working with it again.

Basically echo what Venguard2223 said.  I haven't had time or interest in developing this further.  I actually wanted to develop it out of a mod really and more into a standalone package simply requiring SSI.php to get going and then a integration package.  Reducing the amount of dependencies if possible.

Permissions are a complex thing to do.  Don't think you could have done worse (ha) or better (ha).

I wonder how many places that is...