• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

We've upgraded to XenForo! Help us iron out the bugs!

Status
Not open for further replies.
OK, I'm officially hating the TapTalk app. Is there seriously no way to only see posts from the forums I'm subscribed to?
 
BRAINZ2013 said:
It was earlier but somehow its gone from both online and app.:eek::(
Click to expand...
This is because the default time allowable to edit a post is likely set as 5 minutes. You'll see the edit button up until then. This is a simple value change in the user permission settings.

Note to staff: In ACP > Users > User Group Permissions change the value as indicated in the image shown below to however much time you wish to allow users to edit their post. Set the value to 0 to allow them to edit their posts indefinitely.

View attachment 59615
 
Asylanne said:
This is because the default time allowable to edit a post is likely set as 5 minutes. You'll see the edit button up until then. This is a simple value change in the user permission settings.

Note to staff: In ACP > Users > User Group Permissions change the value as indicated in the image shown below to however much time you wish to allow users to edit their post. Set the value to 0 to allow them to edit their posts indefinitely.

View attachment 59615
Click to expand...
Yes, thank you but the edit button, as I mentioned earlier, is simply not showing up for everyone, time limit notwithstanding.

It's a confirmed observable - and the decision to set a limit in the first place (we did) was just wrong.

This isn't our first Xenforo - it's just our first Xenforo this screwed up. :)

The test site, a full copy of the forums to shake this out (also not our first Xenforo) didn't have these issues.
 
This is an admin note. All others can ignore this:

Setting up permissions... properly.

1. All members should be in the Registered group as their Primary - that includes moderators, administrators and super administrators.

2. Set the Registered user group to the minimum permissions you want all members to have. Set those permissions you want them to have to Allow, leave everything else at Not Set (No).
Do not use Never as it can't be overridden.

3. For any additional user groups, only change the specific permissions which differ from the settings in the Registered user group - all other permissions can be left at Not Set (No) - and add members to them as Secondary groups.

The reason for doing it like this is it makes it very easy to manage every member with a single permission change.

For example, let's assume Edit post by self is not permitted for regular members - so leave it at Not Set (No) for the Registered user group.

Then if you have a trusted user group which is allowed to edit posts, just set that specific permission to Allow, leave everything else at Not Set (No) and add the members you wish to it as a Secondary user group. So it's just a single permission change in that group and any members you now wish to be able to edit posts, you just add them to the group.

However, let's take another scenario.
Let's assume for some reason you have allowed members the ability to delete posts but now you want to stop that. As everyone is in the Registered user group as the primary and that permission is set to Allow, to remove it from everyone all you need to do is set it to Not Set (No).

If you have members in different user groups as their primary or have that permission set to Allow on more than one group, then it won't be quite so simple to do that, you will have to do it for every user group.

You don't need to explicitly set everything to Allow in the trusted member group as those permissions are already set in the Registered user group. The same principle applies to any additional permissions and user groups.

It also applies to nodes, just allow or revoke specific permissions for specific groups as required.

The more user groups you have, the more beneficial this approach becomes.
 
EarlyMon said:
Yes, thank you but the edit button, as I mentioned earlier, is simply not showing up for everyone, time limit notwithstanding.

It's a confirmed observable - and the decision to set a limit in the first place (we did) was just wrong.

This isn't our first Xenforo - it's just our first Xenforo this screwed up. :)

The test site, a full copy of the forums to shake this out (also not our first Xenforo) didn't have these issues.
Click to expand...
Oh okay, sounds good. Good luck getting it all squared away.
 
EarlyMon said:
It's a bug. It's going to be sorted out in a few hours or when it's fixed, whichever comes later.

Sorry.
Click to expand...

Ah! the answer of any IT department. :) A most cromulent (with credit to EarlyMon for extending my vocabulary) statement, guaranteed a satisfactory answer to all but the most intent of listeners. Indeed, the second sentence has been said by me to my boss and to customers with minor paraphrasing.
 
Asylanne said:
This is an admin note. All others can ignore this:

Setting up permissions... properly.

1. All members should be in the Registered group as their Primary - that includes moderators, administrators and super administrators.

2. Set the Registered user group to the minimum permissions you want all members to have. Set those permissions you want them to have to Allow, leave everything else at Not Set (No).
Do not use Never as it can't be overridden.

3. For any additional user groups, only change the specific permissions which differ from the settings in the Registered user group - all other permissions can be left at Not Set (No) - and add members to them as Secondary groups.

The reason for doing it like this is it makes it very easy to manage every member with a single permission change.

For example, let's assume Edit post by self is not permitted for regular members - so leave it at Not Set (No) for the Registered user group.

Then if you have a trusted user group which is allowed to edit posts, just set that specific permission to Allow, leave everything else at Not Set (No) and add the members you wish to it as a Secondary user group. So it's just a single permission change in that group and any members you now wish to be able to edit posts, you just add them to the group.

However, let's take another scenario.
Let's assume for some reason you have allowed members the ability to delete posts but now you want to stop that. As everyone is in the Registered user group as the primary and that permission is set to Allow, to remove it from everyone all you need to do is set it to Not Set (No).

If you have members in different user groups as their primary or have that permission set to Allow on more than one group, then it won't be quite so simple to do that, you will have to do it for every user group.

You don't need to explicitly set everything to Allow in the trusted member group as those permissions are already set in the Registered user group. The same principle applies to any additional permissions and user groups.

It also applies to nodes, just allow or revoke specific permissions for specific groups as required.

The more user groups you have, the more beneficial this approach becomes.
Click to expand...
My public title is moderator but you can trust me to speak for admin on this. ;) :)


Thanks for your help, we appreciate it. :)

Fwiw, each of your posts explaining how to set up permissions properly was very clear.

Phases - the admin you're trying to advise - has seen your posts.

Always nice to meet another Xenforo user! :)
 
EarlyMon said:
My public title is moderator but you can trust me to speak for admin on this. ;) :)


Thanks for your help, we appreciate it. :)

Fwiw, each of your posts explaining how to set up permissions properly was very clear.

Phases - the admin you're trying to advise - has seen your posts.

Always nice to meet another Xenforo user! :)
Click to expand...

I love XenForo, it just takes a bit to get used to. Not for you as you already have used it before, but for your users. They'll grow accustomed in time. I like the style you guys are using btw, very clean.
 
@Asylanne Thanks! :) That's a great way to do it, and how we've done it fresh/new sites - but when importing from a 6 year old VB install with tons of usergroups set up all sorts of matched up - it doesn't translate into something like that in the finished result - as we can see lol..

The importer wasn't wrote to do it that way. In hindsight we should have thought to retool it for that but.. anyway. Maybe we'll go back and revamp it some time to match that model but at any rate that's not related to any of the problems we are having. We're working though them. :) The biggest it appears are related to comb IDs and a mismatch between the live conversion and what was brought in when we imported some of the dev settings to move over some of our work. Seems we overwrote a couple things and found bugs due to the creation of new groups between the two environments when then combined into one.

We'll get it fixed up :)
 
Phases said:
@Asylanne Thanks! :) That's a great way to do it, and how we've done it fresh/new sites - but when importing from a 6 year old VB install with tons of usergroups set up all sorts of matched up - it doesn't translate into something like that in the finished result - as we can see lol..

The importer wasn't wrote to do it that way. In hindsight we should have thought to retool it for that but.. anyway. Maybe we'll go back and revamp it some time to match that model but at any rate that's not related to any of the problems we are having. We're working though them. :) The biggest it appears are related to comb IDs and a mismatch between the live conversion and what was brought in when we imported some of the dev settings to move over some of our work. Seems we overwrote a couple things and found bugs due to the creation of new groups between the two environments when then combined into one.

We'll get it fixed up :)
Click to expand...
Sounds like a headache! lol I wish you guys the best of luck and congratulations on your move!
 
A few other minor bugs I've been putting off -

Rob changed to rob - I guess rob is material design for Rob - so we ought to change it back just because.

He's also listed as Administrator instead of Plenipotentiary.

I'm still listed as Moderator. I think I've earned Martian Ambassador twice over.

If you miss these, I'll be sure to get them on the next list. :)
 
Only a couple bugs I've caught thus far.

The first bug I've noticed was obviously the login (Site and apps). However, shoutout to Unforgiven, Xyro, and Phases for being diligent and extremely supportive to the concerns I voiced.

The second bug I noticed was the Avatar being reverted to an old one and not being able to switch over (Tapatalk and Forums for Android app, this however was an old bug on Forums for Android app) Successfully switched on laptop.

The third one I noticed was on both Tapatalk and Forums for Android. When clicking on Forums button it hangs on "By Category" and on Tapatalk as well. By name works flawlessly though.

Hopefully I shed some light on some bugs that were not addressed.
 
kratos said:
Here is another bug to take a look at:

When navigating to my account by clicking my user name it takes me to the following URL:

http://androidforums.com/account/

At which point I receive the following error:

Android Forums - Error
You do not have permission to view this page or perform this action.

Thoughts?

Kratos
Click to expand...
I get the same issue.
Now that I'm finally logged in I say THANKS to all who worked so hard to make this possible! :) :) :)
 
ldAl4gt

Categories Hanging.

QkITSR1


Error I got when my post wouldn't post and clicked refresh.
 
Status
Not open for further replies.
Back
Top Bottom