Jump to content

Michael

Clients
  • Posts

    23,640
  • Joined

  • Last visited

  • Days Won

    114

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Everything posted by Michael

  1. I think my request is going to be pretty simple, so please bear with the lengthy explanation. I have been working on an application that is trying to utilize the classPost.php file for creating topics, creating replies, and editing posts. It is convenient in that I can set just a few flags and have it do the work for me, but it seems to be a big pain to use it as a real API. The code is littered with all kinds of permission checks that stop me from doing these functions. For example, I'm trying to create a tool that will loop through a series of forum topics and rebuild the content of their first post. I am able to set the content, tell who the author was, what topic ID it was and all that, but the problem is that it's checking to see if the 'author' has edit permissions. The author of the post in question may not, they may even be a guest. But I need my tool, which resides in the ACP, to not check those permissions; just frickin' edit the post already. :P I've already reported one problem with this file and how it forces the 'author' to have 'start topic' permissions in order to create a new topic, here, but that's flagged for a future version, and I fear that future version that it may be considered for is months away, if it will be added at all. This issue I'm running into now is similar, but I haven't been able to hack a workaround for it yet. My request is simple: please add some flag to that file, false by default, that when set to true it bypasses these checks which don't make any sense when the class is being used as an API. I want to be able to use this class to just make new topics, posts, and edits without having to jump through hoops, and I really don't want to have to re-write all of the code without these checks and use it in my application instead.
  2. 1. You could probably use the formatContent function to check permissions and give an error message there. 2. You should only use the "Find in forum:" list if you're going to be looking in forums, see #3 below. 3. You need to add a new section to the advanced search page using the getFilterHTML function, like what IP.Downloads does to show the categories on that page.
  3. IPS shouldn't be interested in duplicating features in vBulletin, what's the point of each forum software doing everything the same? I personally like the way searches work here right now, I remember specific terms in the topics I want to search for and I like that I can see the snippets of the post containing those search terms; I don't always remember topic titles as well.
  4. I agree, reporting this in the tracker doesn't seem like the best plan. It's clearly something that has just occurred at some point in the day today, I'm sure from just something IPS was messing about with and can be quickly fixed once they see this topic.
  5. Is there any plan at some point to allow third party developers the opportunity to have the error code information for their resources made somewhere publicly accessible, like here on the IPS site? I know Mark's been working on this to track all of IP.Board's error codes, but it'd be great if we could add our own error codes into this too. I can include the Excel file of these error codes I created for my app in a documentation folder for it, but that's really only good for the site owner, not the members who might see these errors too.
  6. It's been like this for a while, but hopefully they'll fix this soon: http://community.invisionpower.com/index.php?app=tracker&showissue=18482
  7. Always remember, if you see a search engine spider doing something that you don't think they have permission to do, it typically means they are actually indexing an error page telling them they don't have permission to do whatever it was they were doing.
  8. Michael

    Terms of Use

    Just use the Help system, or an announcement, to create an article for your privacy policy, then skin a link to it wherever you need it to show.
  9. Probably this: http://community.invisionpower.com/topic/293073-error-accessing-company-forums/
  10. Michael

    Terms of Use

    What does that mean? Are you talking about the registration terms people agree to on his forum? Or the license agreement he agreed to when he bought his forum?
  11. Michael

    Terms of Use

    Registered as a member of these forums? Or for the software you purchased?
  12. Michael

    SEF urls

    Thanks, I didn't think so. I'm no SEO guru, but I always thought they meant the same thing, and Google confirmed that when I couldn't find any sites mentioning there being a difference. :lol:
  13. Michael

    SEF urls

    There's a difference between a Friendly URL and Search Engine Friendly URLs? :blink:
  14. If they did something like this, then some folks would complain that they should be included in the group. Should a person who created one really big nice mod be in the group? Or should a person who created 10 small mods that don't really work be in the group? It's too hard to come up with reliable guidelines that they can set as the group requirement, and IPS has enough on their plate as it is.
  15. You can re-enable their PM access via the ACP. Even if you do this, or there was a way to force the PM through like what you suggested, there's no way to prevent them from simply ignoring the PM.
  16. This is a known bug, there are multiple reports of this in the Bug Tracker.
  17. Michael

    Resource Site

    We have some plans in place for cleaning stuff up in there. The searching thing is a pain, I mentioned this in our plans as well. :)
  18. Amen. It's requirements like that that force people to have to write down their passwords, thus defeating the purpose of the security gains you're supposed to be getting from having these requirements.
  19. I hope so too, I'm tired of having to tell people to re-import the hooks. :(
  20. As it says in the fixed issue sunrisecc linked to, this issue will be fixed going forward after the 3.0.3 upgrade.
  21. The issue is easily reproducible using the hooks mentioned that have this issue. The tracker ticket sunrisecc linked to above shows where this was reported as an issue with the 3.0.1 -> 3.0.2 upgrade. If the issue is with my hooks, I'll gladly fix them if I knew what the problem was. EDIT: It only seems to affect hooks that add templates to skin_global, not other groups like skin_boards, as hooks like Group Name Indicator and Members Online Today are unaffected by this issue. This leads me to believe the problem is not with the hooks themselves, but with how skin_global is being handled by IP.Board.
  22. Does't do it at my site, or here, you should open a ticket for support or post in the peer-to-peer forums.
  23. Curse you, Charles. Curse you! :devil:
  24. Skin difference here: No word on any CSS differences yet.
  25. They should not be affected in any way.
×
×
  • Create New...