Messages

  Entire forum

Auto Light Dark

English

I already explained this.

1. Stop adding users to a new group when they register. Just leave it alone.

2. Whatever role you created for users in the helpdesk (as opposed to staff), add the Registered Members group to that role, it should be the first on the list, as per http://www.simpledesk.net/community/index.php?topic=709.0 - last screenshot in the first post, the first group is the registered members group. Any user who just registers will be in that group (even though it will not show it on posts, this is intentional in SMF, but they WILL be in that group)

I haven't got a guide, sorry.

The standard setup would be to either create a new action, or to start with SSI.php before *anything* else, but your integration is something new and short of examining the code myself, there's not a lot I can do. Unfortunately I have neither the time or inclination to take on such a job right now, sorry.

Setting the primary group is for the user itself in the user profile, go to the account settings for a user, and you'll see what that user's primary group is.

It's not about giving credit, it's the fact you have one system that manages to ignore both of the standard, accepted and proven-to-work-with-SimpleDesk to integrate something.

Consider it this way: if it works without error when inside SMF but not outside, that would tend to suggest it's not actually SD that's at fault, nor the code changes mentioned above, but with however the bridge to outside is managed.

I didn't change anything but for whatever reason None of the newly self registered user is assigned to Regular Member.   When I opened the user under their Account Setting >Modify Profile, the Primary Membergroups were left empty

Like I said, crazy setup. If there is no other primary group, they're automatically in the Registered Members group, but since it's not a 'real' group, it doesn't tell you as such. Use THAT group, not the one you keep adding people to.

So I'm guessing either this is a bug or there's something wrong with my installation (Which I doubt).  Unless I'm missing the setting somewhere.  Please advise?

No bug, just you're not using SMF how the designers intended. Every user physically MUST be in two groups at any one time. It simply isn't possible for a user to not be in at least two groups, their post count group and a primary group. If no primary group is given, an internal Registered Members group is used. But if there's no primary group, the group shown up in profiles etc. is the post count group instead.

You don't need to add people to a group, nor do you need to fuss with post counts, just leave people without having a primary group attached and tie their role to the Registered Members group, it should even be the first one on the list in the permissions areas (both SMF and SimpleDesk's)

I think he's assuming the bug tracker is SimpleDesk (it's not, though I always wanted to make the transition)

Registered Members is also one of the craziest setups in SMF itself. You can assign a role within the helpdesk to the registered members group quite happily (i.e. tying registered members to a user role). Basically, any user which doesn't have a 'primary group' set is in the Registered Members group.

I should add, there was never a technical reason why post counts were excluded, it was a conscious logical decision not a technical one; I never saw any real need to tie it to post counts when it should really be about conventional groups. But yes, you can do it for registered members easily enough in the permissions area, I made sure it was an option and use it that way on a site myself.

So you have a module that you haven't explained, with some changes you haven't explained and sadly I can't help you with that because I'm not a mind reader.

I have absolutely no idea how you've managed to integrate the two because it's using a mash-up of two totally different SMF systems.

I'm sorry, I can't help you with this. Trouble is... I doubt anyone else will be able to either.

You should really have the SSI include right up front. That should be taking care of all the inclusion of SD permissions.

Though if it's a template_main function why are you loading SSI.php exactly? That sort of implies you're doing it through an index.php?action=page type function...

Is it the Coppermine stuff itself throwing it or is it definitely the main page load?

That wasn't what I really wanted to know. If you'd like help on fixing this, you do sort of need to provide details of what you've done so I can try to figure out how to change it for you.

Define 'not entirely integrated'.

Still do not see the ~Venguard223 to Gri~ button
anywhere around your post, venguard223 -

That's because there isn't one. Hint: I'm also known as Arantor and no, there isn't a ~Arantor to Gri~ topic because it would be locked.

Please quote my question in global format
and strike out the word "Where".

Please stop.

Go away. Your nonsense about SMF is not wanted here.

So did you create some roles for the department? Did you add some groups to those roles?

I mean, it's in the department screen as to which roles are in that department, and it's in the permissions screen, and Admin > Helpdesk > Permissions is too hard to find?

* venguard223 is not being funny, but I fail to understand how it can be as difficult as it is to find this stuff.

So the WSOD is an out of memory issue, that seems reasonable.

Definitely means ticket logs need pagination. Can't remember how much of a pain that would be to implement, I have a feeling that it doesn't use the generic list structure, which makes pagination even more of a pain.

If the forum is set up as UTF-8 in the first instance it should never be a problem

The writing-in-Word is because Word adds non-standard characters for the smart quotes.